Was macht select(2), wenn Sie einen Dateideskriptor in einem separaten Thread schließen(2)?

Wie ist das Verhalten der select(2) Funktion, wenn ein Dateideskriptor, den es zum Lesen überwacht, von einem anderen Thread geschlossen wird?

Nach einigen flüchtigen Tests kehrt es sofort zurück. Ich vermute, das Ergebnis ist entweder, dass (a) es immer noch auf Daten wartet, aber wenn Sie tatsächlich versuchen würden, daraus zu lesen, würden Sie EBADF erhalten (möglicherweise – es gibt ein potenzielles Rennen) oder (b) dass es so tut, als ob der Dateideskriptor wurde nie übergeben. Wenn der letztere Fall zutrifft, würde die Übergabe eines einzelnen fd ohne Zeitüberschreitung einen Deadlock verursachen, wenn es geschlossen würde.

Aus einigen zusätzlichen Untersuchungen geht hervor, dass sowohl dwc als auch Bothie recht haben.

Bothies Antwort auf die Frage läuft darauf hinaus: Es ist undefiniertes Verhalten. Das bedeutet nicht, dass es unbedingt unvorhersehbar ist, aber dass verschiedene Betriebssysteme es unterschiedlich machen. Es scheint, dass Systeme wie Solaris und HP-UX zurückkehren select(2) in diesem Fall basiert Linux aber nicht auf diesen Beitrag an die Linux-Kernel-Mailingliste ab 2001.

Das Argument auf der Linux-Kernel-Mailingliste ist im Wesentlichen, dass es sich um ein undefiniertes (und fehlerhaftes) Verhalten handelt, auf das man sich verlassen kann. Im Fall von Linux das Aufrufen close(2) auf dem Dateideskriptor dekrementiert effektiv einen Referenzzähler darauf. Da es eine select(2) rufen Sie auch mit einem Verweis darauf auf, der fd bleibt geöffnet und wartet auf Eingaben, bis die select(2) kehrt zurück. Dies ist im Grunde die Antwort von dwc. Sie erhalten ein Ereignis für den Dateideskriptor und dann wird es geschlossen. Der Versuch, daraus zu lesen, führt zu einem EBADF, vorausgesetzt, die fd wurde nicht recycelt. (Eine Sorge, die MarkR in seiner Antwort geäußert hat, obwohl ich denke, dass sie in den meisten Fällen bei richtiger Synchronisierung wahrscheinlich vermeidbar ist.)

Also danke an alle für die Hilfe.

Ich würde erwarten, dass es sich so verhalten würde, als wäre das Dateiende erreicht worden, das heißt, es würde mit dem als bereit angezeigten Dateideskriptor zurückkehren, aber jeder Versuch, es anschließend zu lesen, würde “schlechter Dateideskriptor” zurückgeben.

Allerdings ist dies sowieso eine sehr schlechte Übung, da Sie immer potenzielle Rennbedingungen haben würden Ein weiterer Dateideskriptor mit der gleichen Nummer könnte sofort von einem anderen Thread geöffnet werden, nachdem der andere 2. ihn geschlossen hat, dann würde der ausgewählte Thread am Ende auf den falschen warten.

Sobald Sie eine Datei schließen, wird ihre Nummer zur Wiederverwendung verfügbar und kann beim nächsten Aufruf von open(), socket() usw. wiederverwendet werden, selbst wenn von einem anderen Thread. Deshalb müssen Sie solche Dinge wirklich, wirklich vermeiden.

Der Select-Systemaufruf ist eine Möglichkeit, darauf zu warten, dass Dateideskriptoren den Status ändern, während die Programme nichts anderes zu tun haben. Die Hauptanwendung sind Serveranwendungen, die eine Reihe von Dateideskriptoren öffnen und dann darauf warten, dass etwas mit ihnen geschieht (neue Verbindungen akzeptieren, Anforderungen lesen oder Antworten senden). Diese Dateideskriptoren werden im nicht blockierenden IO-Modus geöffnet, sodass der Serverprozess zu keinem Zeitpunkt in einem Systemaufruf hängen bleibt.

Dies bedeutet außerdem, dass keine separaten Threads erforderlich sind, da die gesamte Arbeit, die im Thread erledigt werden könnte, auch vor dem Select-Aufruf erledigt werden kann. Und wenn die Arbeit lange dauert, dann kann sie unterbrochen werden, Aufruf mit timeout={0,0} auswählen, die Dateideskriptoren werden verarbeitet und danach wird die Arbeit wieder aufgenommen.

Jetzt schließen Sie einen Dateideskriptor in einem anderen Thread. Warum haben Sie überhaupt diesen zusätzlichen Thread und warum soll er den Dateideskriptor schließen?

Der POSIX-Standard gibt keine Hinweise, was in diesem Fall passiert, Sie machen also UNDEFINED BEHAVIOR. Erwarten Sie, dass das Ergebnis zwischen verschiedenen Betriebssystemen und sogar zwischen Versionen desselben Betriebssystems sehr unterschiedlich sein wird.

Gruß Bodo

Es ist ein wenig verwirrend, was Sie fragen …

Select() sollte bei einer “interessanten” Änderung zurückkehren. Wenn close() lediglich die Referenzzählung verringert hat und die Datei noch irgendwo zum Schreiben geöffnet war, gibt es keinen Grund für select() aufzuwachen.

Wenn der andere Thread close() auf dem einzigen offenen Deskriptor ausgeführt hat, wird es interessanter, aber ich müsste eine einfache Version des Codes sehen, um zu sehen, ob etwas wirklich falsch ist.