Ich habe die Implementierung der Abbruchpunkte von glibc / nptl untersucht und mit POSIX verglichen, und wenn ich mich nicht irre, ist das völlig falsch. Das verwendete Grundmodell ist:
%Vor%Nach POSIX:
Die Nebeneffekte des Einwirkens auf eine Abbruchanforderung, während sie während eines Aufrufs einer Funktion unterbrochen sind, sind die gleichen wie die Nebenwirkungen, die in einem single-threaded-Programm auftreten können, wenn ein Aufruf einer Funktion durch ein Signal unterbrochen wird und die gegebene Funktion gibt [EINTR] zurück. Solche Nebenwirkungen treten auf, bevor Stornierungsbereinigungshandler aufgerufen werden.
Wenn ich% code% anrufe, kann ich erwarten, dass entweder abgebrochen wird (zusammen mit meinem ganzen Thread), bevor es die Datei nicht öffnet oder , um einen gültigen Dateideskriptor oder -1 und open -Wert zurückzugeben, aber niemals einen neuen Dateideskriptor zu erstellen, dann diesen in das void zu verlieren. Auf der anderen Seite scheint die glibc / nptl-Implementierung von Abbruchpunkten eine Race-Bedingung zu ermöglichen, bei der die Abbruchanforderung unmittelbar nach dem Zurücksenden des syscall auftritt, aber bevor errno stattfindet.
Bin ich verrückt oder ist ihre Umsetzung wirklich so kaputt? Und wenn ja, erlaubt POSIX ein solches kaputtes Verhalten (was die Annullierung vollständig unbrauchbar macht, wenn Sie es nicht manuell verschieben), oder ignorieren sie POSIX schlicht und einfach?
Wenn dieses Verhalten tatsächlich gebrochen ist, was ist der richtige Weg, es ohne eine solche Race Condition zu implementieren?
Ist dies nicht im nächsten Absatz der Norm geklärt?
Allerdings, wenn der Thread bei suspendiert ist ein Absagepunkt und das Ereignis für was es wartet, tritt vor dem Stornierungsanfrage wird darauf reagiert ist nicht angegeben, ob die Stornierungsanfrage wird bearbeitet oder ob die Stornierungsanfrage bleibt ausstehend und der Thread wird fortgesetzt normale Ausführung.
Was impliziert, dass diese Rassenbedingung vollkommen legales Verhalten ist.