blockierende funktionen?
-
hallo,
ich habe eine verständnisfrage zu sogenannten (das hab ich mal aufgeschnappt) "blockierenden funktionen".
da das sicherlich n überladener begriff ist: ich meine z.B. eine funktion wie read()
anscheinend ist es irgendwie so, dass ein read-Aufruf so lange blockiert, bis er etwas lesen kann. d.h. das programm hängt in der zeile fest.
meine frage: wann ist das der fall? z.B. bei read von einem file-deskriptor auf eine datei, in der nichts steht (0 byte) bleibt er ja nicht hängen und wartet.
wartet er bei pipes/fifos, wenn die andere seite offen ist?
ich weiss halt nicht, wann z.B. read() sich so "blockierend" verhält und wann es einfach einen rückgabewert von 0 oder auch -1 zurückgibt.
wär dankbar für ne erklärungen, da ich dazu in der manpage nichts finden kann.
-
normalerweise kann so'n programm viel schneller ablaufen, als zeichen aus einer datei gelesen werden können. um das programm zu auszubremsen, kann man z.b. mit blockierenden funktionen arbeiten. die funktion kehrt erst zurück, wenn mindestens ein zeichen aus der datei gelesen wurde, der filepointer am ende angekommen, oder ein fehler passiert ist. bei nichtblockierenden funktionen muss man z.b. den rückgabewert ständig prüfen, ob etwas gelesen wurde oder nicht.
-
ja aber wie gesagt, ein file mit 0 byte lesen gibt doch sofort den return wert 0 (0 byte gelesen), und hängt sich nicht auf und wartet, bis plötzlich was im file steht.
anders gesagt: wann kommt ein filedeskriptor "ans ende" und wann blockiert er?
-
hdi-lo schrieb:
ja aber wie gesagt, ein file mit 0 byte lesen gibt doch sofort den return wert 0 (0 byte gelesen), und hängt sich nicht auf und wartet, bis plötzlich was im file steht.
so ungefähr sollte es sein.
hdi-lo schrieb:
anders gesagt: wann kommt ein filedeskriptor "ans ende" und wann blockiert er?
naja, wenn du permanent aus dem file liest, kommste logischerweise irgendwann ans ende. blockieren wird's nur kurzzeitig, während die bytes vom pysikalischen medium in den lesebuffer transferiert werden.
-
mit read kannst nicht nur aus Dateien lesen sondern auch aus sockets, pipes, fifos usw und diese sind nicht unbedingt endlich. Ein socket z.b. mit dem du Daten über Netzwerk überträgst, kann dazu führen, dass read blockiert, wenn die Senderseite keine weitern Daten sendet und die Verbindung trotzdem aufrecht erhält. Um sich davor zu schützen kann man den socket nicht-blockierend machen oder timeouts festlegen. Mehr Information findest du unter man: select(2) aber das hat nichts mit ANSI C zu tun.
-
Ein Beispiel zu freaks Erklärung: Du liest aus einer Datei einen 10 MB großen Block. Jetzt ist aber die CPU fürchterlich schnell, und die Festplatte fürchterlich lahm, so dass das Lesen dieser 10 MB sagen wir 1 Sek. dauert. Wenn du jetzt ein nicht-blockierendes read() benutzen würdest, würde das sofort zurückkehren und evtl. vermelden "konnte noch keine 10 MB lesen, frag mich später nochmal". Ein blockierendes read() würde diese 1 Sek. warten, bis die 10 MB gelesen werden konnten.