dürfen epoll (unter Linux) für normale Dateien irgendwie nützlich sein? Ich weiß, dass es hauptsächlich mit Steckdosen verwendet wird, aber ich frage mich nur.
Epoll auf reguläre Dateien
Lesezeit: 3 Minuten
13714200cookie-checkEpoll auf reguläre Dateien
Nicht wirklich. epoll macht nur Sinn für Dateideskriptoren, die normalerweise ein Blockierverhalten beim Lesen/Schreiben zeigen würden, wie Pipes und Sockets. Normale Dateideskriptoren geben immer entweder ein Ergebnis oder das Dateiende mehr oder weniger sofort zurück, also epoll würde nichts Nützliches für sie tun.
-
Das heißt, es funktioniert, wenn auch bedeutungslos: “Die Funktion poll() soll reguläre Dateien unterstützen … Reguläre Dateien sollen immer TRUE zum Lesen und Schreiben abfragen.” pubs.opengroup.org/onlinepubs/009695399/functions/poll.html Auf der epoll(4)-Manpage heißt es: “Bei Verwendung als Level-Triggered-Interface ist epoll auf jeden Fall eine schnellere Abfrage(2) und kann überall dort verwendet werden, wo letzteres verwendet wird, da es die gleiche Semantik hat.” Daher wird es, wie Duskwuff sagt, nichts Nützliches tun.
– mkj
8. November 2011 um 22:35 Uhr
-
Was so dumm und falsch ist. Der Kernel kann aus vielen Gründen aufhängen, vom Hochfahren der Festplatte (im Ruhezustand) bis hin zu Netzwerkverzögerungen von einer im Netzwerk bereitgestellten Freigabe/Laufwerk. Jede Art von Geräteinteraktion kann zu einem IO-Hang führen. select/epoll/poll/kqueue sollte so gemacht werden, dass es mit jedem Dateideskriptor funktioniert, und jede Dateibeschreibung sollte eine Nichtblockierung zulassen.
– Rahly
18. Juni 2017 um 23:25 Uhr
-
@Rahly Das ist nicht möglich. Der Kernel weiß nicht im Voraus, ob ein Schreibvorgang in eine Datei blockiert – im Gegensatz zu Sockets oder Pipes sind Puffer für Dateisystemschreibvorgänge nicht einem einzelnen FD zugeordnet, daher gibt es keine Möglichkeit zu garantieren, dass sie für einen bestimmten Prozess verfügbar sind .
– Benutzer149341
19. Juni 2017 um 0:09 Uhr
-
@duskwuff sicher kann es, es entscheidet sich nur aufgrund bestimmter Einschränkungen dagegen. Beispielsweise weiß der Kernel, was die Puffer enthalten. Epoll im Allgemeinen ist keine Garantie für irgendetwas. Nur mehr als wahrscheinlich. Theoretisch könnte Readahead das System nach bestimmten Daten “fragen” und ein EPOLLIN/EPOLLERR-Signal in die Epoll-Warteschlange stellen. Auch, nur weil es es NICHT tut, heißt das nicht, dass es immer noch nicht albern und/oder falsch ist. Wie die Implementierung erfolgt, ist für die Funktionsweise irrelevant.
– Rahly
19. Juni 2017 um 0:18 Uhr
-
Im dieses Repo heißt es das „Linux bietet nur eingeschränkte Unterstützung für die Verwendung von epoll als Mechanismus für asynchrone E/A […] Wenn die Datei als O_NONBLOCK geöffnet wird, gibt ein Lesevorgang EAGAIN zurück, bis sich der relevante Teil im Speicher befindet., was dieser Antwort widerspricht. Aber in einem einfachen Test konnte ich das nicht bestätigen. Wer hat Recht?
– nh2
14. Mai 2018 um 1:01 Uhr
osgx
Ich denke, es wird bei epoll_ctl mit scheitern EPERM:
EPERM The target file fd does not support epoll.
wenn die Datei keine hat poll() Schnittstelle.
Der eigentliche Code ist http://lxr.linux.no/#linux+v3.1/fs/eventpoll.c#L1373
1373 /* The target file descriptor must support poll */
1374 error = -EPERM;
1375 if (!tfile->f_op || !tfile->f_op->poll)
1376 goto error_tgt_fput;
1377
