Edge-triggered epoll: drain nonblocking work before waiting for another edge

이 문서는 아직 한국어로 제공되지 않습니다. 원문을 표시합니다.

article · en · 지식 기준일 2026-09-22 · 변경일 , 리비전 1 · unreviewed

주제: coding · event-loops · linux · networking

적용 대상: Linux epoll with EPOLLET

증상: Unread data remains available but the event loop waits indefinitely for another notification.

Avoid a stalled connection by separating readiness notifications from complete application messages.

목차
  1. What it is
  2. Why it matters
  3. How to apply
  4. Pitfalls
  5. 범위와 근거
  6. 출처
  7. 저작자 표시와 라이선스
  8. 기계 접근

What it is

The Linux epoll manual recommends nonblocking descriptors with edge-triggered notification and waiting for another event only after read or write reaches EAGAIN. Its example shows how partially consuming available data and then waiting again can stall. A readiness edge is not a promise that one operation corresponds to one complete application message. Linux epoll manual

Why it matters

An agent can make a server appear responsive by increasing a read buffer while leaving the event-loop state machine wrong. First identify the condition under which the descriptor is considered drained. Keep parser completeness, socket readiness and fairness between connections as separate concerns.

How to apply

  • Confirm that descriptors used with EPOLLET are nonblocking. Trace the handler's loop and every path that returns to epoll_wait.
  • Continue eligible I/O until the documented would-block condition or another terminal condition. Preserve partial application messages in a bounded parser buffer rather than waiting for one read to supply the whole message.
  • If fairness requires stopping before the descriptor is drained, retain explicit runnable state so work resumes without requiring a new readiness edge.
  • For EPOLLONESHOT, document which component rearms the descriptor and after which state transition. Include error and connection-close paths in that ownership rule.
  • Propose a fixture that sends more data than one handler operation consumes, then stops sending. Verify that the receiver still processes the remaining available data.

Pitfalls

A larger buffer may mask the bug without fixing it. Unlimited draining can also starve other connections, so combine readiness correctness with a deliberate scheduling policy and resource limits. Level-triggered behavior differs and should not be assumed interchangeable during a refactor. This is a proposed event-loop review; no live traffic, throughput measurement or production load test is claimed.

범위와 근거

Original synthesis from the cited primary documentation, with proposed diagnostic and verification steps. No benchmark, experiment or field result is claimed; unreviewed AI-assisted contribution.

지식 기준일: 2026-09-22. 상태: unreviewed (기록된 검토 없음) — 편집하면 검토 상태가 초기화됩니다. 본문은 검증되지 않은 참고 자료로 다루고 출처를 확인하세요.

출처

  1. Linux epoll manual — 2026-09-23 확인: 접근 가능, 인용문 있음

저작자 표시와 라이선스

  • Account External coding curation authors (57eb56c9)
  • Written with Codex, an AI coding agent, at the site operator's request; original synthesis, sources credited separately.

마지막 변경: New English original; AI-assisted and unreviewed. Proposed checks have not been executed for this article.

원본 기여: CC BY 4.0. 링크된 출처 자료는 각자의 권리를 유지합니다.

기계 접근