epoll en mode déclenché par front : vider le travail non bloquant avant d'attendre un nouveau front

Ce que c'est

Le manuel Linux d'epoll recommande des descripteurs non bloquants avec notification déclenchée par front, et d'attendre un nouvel événement seulement après que la lecture ou l'écriture atteint EAGAIN. Son exemple montre comment le fait de ne consommer que partiellement les données disponibles, puis d'attendre à nouveau, peut bloquer la connexion. Un front de disponibilité n'est pas une promesse qu'une opération correspond à un message applicatif complet. Manuel Linux epoll

Pourquoi c'est important

Un agent peut donner l'illusion qu'un serveur répond correctement en augmentant un tampon de lecture, tout en laissant la machine à états de la boucle d'événements incorrecte. Identifier d'abord la condition sous laquelle le descripteur est considéré comme vidé. Garder séparées la complétude de l'analyseur, la disponibilité du socket et l'équité entre connexions.

Comment l'appliquer

• Confirmer que les descripteurs utilisés avec EPOLLET sont non bloquants. Tracer la boucle du gestionnaire et chaque chemin qui retourne vers epoll_wait.
• Poursuivre les E/S éligibles jusqu'à la condition documentée de blocage (would-block) ou une autre condition terminale. Conserver les messages applicatifs partiels dans un tampon d'analyseur borné, plutôt que d'attendre qu'une seule lecture fournisse le message entier.
• Si l'équité impose d'arrêter avant que le descripteur ne soit vidé, conserver un état explicite d'exécutabilité afin que le travail reprenne sans nécessiter un nouveau front de disponibilité.
• Pour EPOLLONESHOT, documenter quel composant réarme le descripteur et après quelle transition d'état. Inclure les chemins d'erreur et de fermeture de connexion dans cette règle de responsabilité.
• Proposer un fixture qui envoie plus de données qu'une seule opération du gestionnaire n'en consomme, puis cesse d'envoyer. Vérifier que le récepteur traite malgré tout les données restantes disponibles.

Pièges

Un tampon plus grand peut masquer le bug sans le corriger. Un vidage illimité peut aussi affamer d'autres connexions ; combiner donc la correction de la disponibilité avec une politique d'ordonnancement délibérée et des limites de ressources. Le comportement déclenché par niveau diffère et ne doit pas être supposé interchangeable lors d'un remaniement. Il s'agit d'une revue de boucle d'événements proposée ; aucun trafic réel, aucune mesure de débit ni aucun test de charge en production n'est revendiqué.