Edge-triggered epoll: nicht blockierende Arbeit restlos abarbeiten, bevor auf die nächste Edge gewartet wird

Worum es geht

Das Linux-epoll-Handbuch empfiehlt nicht blockierende Deskriptoren mit flankengesteuerter (edge-triggered) Benachrichtigung und rät, erst nach einem EAGAIN von Lesen oder Schreiben auf ein weiteres Ereignis zu warten. Sein Beispiel zeigt, wie ein teilweises Verarbeiten verfügbarer Daten mit anschliessendem erneuten Warten zu einem Stillstand führen kann. Eine Bereitschafts-Edge ist kein Versprechen, dass eine Operation genau einer vollständigen Anwendungsnachricht entspricht. Linux-epoll-Handbuch

Warum es wichtig ist

Ein Agent kann einen Server responsiv erscheinen lassen, indem er einen Lesepuffer vergrössert, während die Zustandsmaschine der Ereignisschleife fehlerhaft bleibt. Zuerst die Bedingung ermitteln, unter der ein Deskriptor als geleert gilt. Vollständigkeit des Parsers, Bereitschaft des Sockets und Fairness zwischen Verbindungen als getrennte Belange behandeln.

So wird es angewendet

• Bestätigen, dass mit EPOLLET verwendete Deskriptoren nicht blockierend sind. Die Schleife des Handlers und jeden Pfad zurück zu epoll_wait nachverfolgen.
• Geeignete E/A fortsetzen, bis die dokumentierte Would-block-Bedingung oder eine andere Abschlussbedingung erreicht ist. Teilweise Anwendungsnachrichten in einem begrenzten Parserpuffer aufbewahren, statt darauf zu warten, dass ein einziges Lesen die gesamte Nachricht liefert.
• Falls Fairness erfordert, vor dem vollständigen Leeren des Deskriptors zu stoppen, einen expliziten lauffähigen Zustand behalten, damit die Arbeit ohne eine neue Bereitschafts-Edge fortgesetzt werden kann.
• Für EPOLLONESHOT dokumentieren, welche Komponente den Deskriptor nach welchem Zustandsübergang erneut scharf schaltet. Fehler- und Verbindungsabbau-Pfade in diese Zuständigkeitsregel einbeziehen.
• Eine Testvorrichtung vorschlagen, die mehr Daten sendet, als eine Handler-Operation verarbeitet, und dann das Senden stoppt. Prüfen, dass der Empfänger die verbleibenden verfügbaren Daten trotzdem verarbeitet.

Stolpersteine

Ein grösserer Puffer kann den Fehler verdecken, ohne ihn zu beheben. Unbegrenztes Leeren kann zudem andere Verbindungen aushungern lassen; deshalb Korrektheit der Bereitschaftsbehandlung mit einer bewussten Scheduling-Strategie und Ressourcengrenzen kombinieren. Level-getriggertes Verhalten unterscheidet sich und sollte bei einem Refactoring nicht als austauschbar angenommen werden. Dies ist eine vorgeschlagene Überprüfung der Ereignisschleife; es wird kein Live-Traffic, keine Durchsatzmessung und kein Produktionslasttest beansprucht.