Linux: was können Sie epolieren?

Anfang dieses Jahres habe ich behauptet, dass epoll die API sei, die das moderne Internet antreibt, aber was kann man eigentlich mit epoll machen?

Sobald wir unsere Anwendung um eine epoll-Ereignisschleife herum strukturiert oder eine asynchrone Engine wie Go oder Rusts tokio verwendet haben, wird es wirklich nützlich, alles andere in diese Ereignisschleife einzufügen.< /p> Welche Art von Dateideskriptoren können Sie zu epoll_ctl hinzufügen? Was können Sie in einen Dateideskriptor umwandeln?

Ich konnte keine vollständige Liste von epoll-kompatiblen APIs im Internet finden, also habe ich eine erstellt.

Netzwerksteckdosen

Netzwerksteckdosen sind der Grund, warum wir epoll wollen und verwenden. Es handelt sich fast immer um IP-Sockets (TCP und UDP), aber es funktioniert auch mit weniger verbreiteten Familien wie UNIX, PACKET, NETLINK und vielen anderen. Tatsächlich sollte es mit allen Socket-unterstützten Protokollfamilien funktionieren, obwohl ich sie nicht alle getestet habe.

timerfd_create ermöglicht es uns, einen einzelnen oder sich wiederholenden Timer zu erstellen und einen Dateideskriptor dafür zu erhalten, der bereit ist, wenn der Timer ausgelöst wird. Ideal für asynchronen Ruhezustand oder Timeout.

signalfd gibt uns einen Dateideskriptor, der bereit wird, wenn ein Betriebssystemsignal ausgelöst wird. Beispiele für die Verwendung sind die Anweisung an ein Programm, seine Konfiguration in SIGHUP neu zu laden, oder das Protokollieren von Debug-Informationen in SIGUSR1.

Dateisystemereignisse

Die inotify-API ermöglicht es uns, das Dateisystem auf Ereignisse wie Dateierstellung und -änderung zu überwachen. Der von inotify_init zurückgegebene Dateideskriptor kann mit epoll abgefragt werden. Beispiele für die Verwendung sind das Neuladen einer Konfigurationsdatei, wenn sie sich ändert, und das Aufwachen, wenn neue Daten in einem Verzeichnis erscheinen.

Untergeordnete Prozesse

Wir können einen Dateideskriptor für einen untergeordneten Prozess erhalten, indem wir entweder das Flag CLONE_PIDFD auf clone setzen oder pidfd_open aufrufen. Es wird bereit, wenn der Prozess abgeschlossen ist. Nützlich, um Unterprozesse zu überwachen und zu verhindern, dass sie zu Zombies werden. Wenn wir den Exit-Code brauchen, würden wir waitid aufrufen, nachdem epoll sagt, dass es fertig ist.

Terminals

epoll akzeptiert fds von Terminals und Pseudo-Terminals. Es akzeptiert fd 0 (stdin), 1 (stdout) und 2 (stderr). Dies ist nützlich für Programme, die für die Verwendung in einer cmd-Zeilenleitung oder als Unterprozess entwickelt wurden, bei dem der übergeordnete Prozess in seine Standardeingabe schreibt und von seiner Standardausgabe liest.

Es ermöglicht uns auch, unseren Servern einen interaktiven Operator-/Debug-Modus zu geben und ihn mit der Hauptereignisschleife zu verbinden. Es macht auch großen Spaß damit zu experimentieren.

Gründung von Epoll

epoll_create gibt einen Dateideskriptor zurück, der selbst über epoll_ctl überwacht werden kann. Dies ermöglicht den Aufbau einer mehrstufigen Hierarchie von Epoll-Listenern.

Benachrichtigungen: Der Plan Alles andere

Wenn unsere asynchrone Engine den Kernel nicht um eine asynchrone (Epoll-fähige) Benachrichtigung bitten kann, wenn eine Aufgabe abgeschlossen ist, müssen wir diese Aufgabe in einem anderen Thread ausführen. Alles, was wir dann brauchen, ist eine Möglichkeit für diesen Thread, die Ereignisschleife zu benachrichtigen, wenn sie beendet ist. Es gibt vier abrufbare Möglichkeiten für Prozesse oder Threads, um zu kommunizieren:

POSIX-Nachrichtenwarteschlangen: siehe man 7 mq_overview.

UNIX-Socket-Paare: man socketpair.

Pipes (oder FIFOs, auch bekannt als Pipe): 7-Mann-Pipe.

eventfd: eventfd wurde genau für unseren Anwendungsfall entwickelt und ist eine moderne Alternative zu Kanälen für abrufbare Signalisierung. Verfügt über eine optionale Semaphor-Semantik. Von man eventfd:

Anwendungen können einen eventfd-Dateideskriptor anstelle einer Pipe in allen Fällen verwenden, in denen eine Pipe einfach zum Signalisieren von Ereignissen verwendet wird. Der Kernel-Overhead eines eventfd-Dateideskriptors ist viel geringer als der einer Pipe, und es wird nur ein Dateideskriptor benötigt (im Gegensatz zu den zwei, die für eine Pipe erforderlich sind).

Und was Sie nicht auslesen können: normale Dateien

Der Aufruf von epoll_ctl mit einer normalen Datei (Festplatte) gibt zurück...