epoll con disparo por flanco: agotar el trabajo no bloqueante antes de esperar otro flanco

Qué es

El manual de epoll de Linux recomienda usar descriptores no bloqueantes con notificación por flanco (edge-triggered) y esperar otro evento solo después de que la lectura o la escritura alcancen EAGAIN. Su ejemplo muestra cómo consumir parcialmente los datos disponibles y luego volver a esperar puede provocar un estancamiento. Un flanco de disponibilidad no es una promesa de que una operación corresponda a un mensaje de aplicación completo. Manual de epoll de Linux

Por qué importa

Un agente puede hacer que un servidor parezca responder correctamente con solo aumentar un búfer de lectura, dejando mal la máquina de estados del bucle de eventos. Conviene identificar primero la condición bajo la cual se considera agotado el descriptor. Conviene mantener como asuntos separados la completitud del analizador, la disponibilidad del socket y la equidad entre conexiones.

Cómo aplicarlo

• Confirmar que los descriptores usados con EPOLLET son no bloqueantes. Rastrear el bucle del manejador y cada ruta que regresa a epoll_wait.
• Continuar con la E/S elegible hasta la condición documentada de bloqueo inminente u otra condición terminal. Preservar los mensajes de aplicación parciales en un búfer de analizador acotado, en lugar de esperar a que una sola lectura provea el mensaje completo.
• Si la equidad exige detenerse antes de agotar el descriptor, conservar un estado ejecutable explícito para que el trabajo se reanude sin requerir un nuevo flanco de disponibilidad.
• Para EPOLLONESHOT, documentar qué componente vuelve a armar el descriptor y tras qué transición de estado. Incluir en esa regla de propiedad las rutas de error y de cierre de conexión.
• Proponer un fixture que envíe más datos de los que consume una operación del manejador y que luego deje de enviar. Verificar que el receptor siga procesando los datos disponibles restantes.

Trampas

Un búfer más grande puede enmascarar el error sin corregirlo. Agotar sin límite también puede dejar sin recursos a otras conexiones, así que conviene combinar la corrección de la disponibilidad con una política de planificación deliberada y con límites de recursos. El comportamiento por nivel (level-triggered) es distinto y no debe asumirse intercambiable durante una refactorización. Esta es una revisión propuesta del bucle de eventos; no se afirma tráfico en vivo, medición de rendimiento ni prueba de carga en producción.