Nicht blockierende UNIX-E/A: O_NONBLOCK vs. FIONBIO

In jedem Beispiel und jeder Diskussion, auf die ich im Zusammenhang mit der BSD-Socket-Programmierung stoße, scheint es, dass der empfohlene Weg, einen Dateideskriptor in den nicht blockierenden I/O-Modus zu setzen, die Verwendung von ist O_NONBLOCK Flagge zu fcntl()z.B

int flags = fcntl(fd, F_GETFL, 0);
fcntl(fd, F_SETFL, flags | O_NONBLOCK);

Ich beschäftige mich seit über zehn Jahren mit der Netzwerkprogrammierung unter UNIX und habe immer die FIONBIO ioctl() Aufruf dazu:

int opt = 1;
ioctl(fd, FIONBIO, &opt);

Habe nie wirklich darüber nachgedacht, warum. Habe es gerade so gelernt.

Hat jemand einen Kommentar zu den möglichen jeweiligen Vorzügen des einen oder anderen? Ich stelle mir vor, dass sich der Portabilitäts-Locus etwas unterscheidet, weiß aber nicht, inwieweit das so ist ioctl_list(2) spricht nicht zu diesem Aspekt des Individuums ioctl Methoden.

Vor der Standardisierung gab es ioctl(…FIONBIO…) und fcntl(…O_NDELAY…), aber diese verhielten sich zwischen Systemen und sogar innerhalb desselben Systems uneinheitlich. Zum Beispiel war es üblich für FIONBIO an Steckdosen zu arbeiten u O_NDELAY um an ttys zu arbeiten, mit vielen Inkonsistenzen für Dinge wie Pipes, Fifos und Geräte. Und wenn Sie nicht wissen, welche Art von Dateideskriptor Sie haben, müssen Sie beide festlegen, um sicherzugehen. Aber auch ein nicht blockierender Lesevorgang ohne verfügbare Daten wurde widersprüchlich angezeigt; Abhängig vom Betriebssystem und dem Typ des Dateideskriptors kann der Lesevorgang 0 oder -1 mit Fehlernummer EAGAIN oder -1 mit Fehlernummer EWOULDBLOCK zurückgeben. Noch heute Einstellung FIONBIO oder O_NDELAY unter Solaris bewirkt, dass ein Lesevorgang ohne Daten 0 auf einem tty oder einer Pipe oder -1 mit errno EAGAIN auf einem Socket zurückgibt. 0 ist jedoch mehrdeutig, da es auch für EOF zurückgegeben wird.

POSIX ging darauf mit der Einführung von ein O_NONBLOCK, das über verschiedene Systeme und Dateideskriptortypen hinweg ein standardisiertes Verhalten aufweist. Da bestehende Systeme normalerweise Verhaltensänderungen vermeiden möchten, die die Abwärtskompatibilität beeinträchtigen könnten, hat POSIX ein neues Flag definiert, anstatt ein bestimmtes Verhalten für eines der anderen vorzuschreiben. Einige Systeme wie Linux behandeln alle 3 gleich und definieren auch EAGAIN und EWOULDBLOCK mit demselben Wert, aber Systeme, die ein anderes Legacy-Verhalten für die Abwärtskompatibilität beibehalten möchten, können dies tun, wenn die älteren Mechanismen verwendet werden.

Neue Programme verwenden sollten fcntl(…O_NONBLOCK…)wie von POSIX standardisiert.

Wie @ Sean sagte, fcntl() ist weitgehend standardisiert und damit plattformübergreifend verfügbar. Das ioctl() Funktion älter fcntl() in Unix, ist aber überhaupt nicht standardisiert. Dass die ioctl() auf allen für Sie relevanten Plattformen für Sie gearbeitet hat, ist glücklicherweise, aber nicht garantiert. Insbesondere die für das zweite Argument verwendeten Namen sind geheimnisvoll und nicht plattformübergreifend zuverlässig. Tatsächlich sind sie oft eindeutig für den bestimmten Gerätetreiber, auf den der Dateideskriptor verweist. (Das ioctl() Aufrufe, die für ein Bitmap-Grafikgerät verwendet wurden, das auf einem ICL Perq mit PNX (Perq Unix) von vor zwanzig Jahren lief, wurden zum Beispiel nirgendwo anders übersetzt.)

Ich glaube fcntl() ist eine POSIX-Funktion. Wohingegen ioctl() ist eine Standard-UNIX-Sache. Hier ist eine Liste von POSIX io. ioctl() ist eine sehr Kernel/Treiber/OS-spezifische Sache, aber ich bin sicher, was Sie verwenden, funktioniert auf den meisten Unix-Varianten. manch andere ioctl() Dinge funktionieren möglicherweise nur auf bestimmten Betriebssystemen oder sogar auf bestimmten Versionen des Kernels.