readiness model:  "지금 읽거나 쓸 수 있음"을 알림 -> application이 I/O 수행
completion model: I/O를 먼저 요청 -> 완료된 결과와 byte 수를 나중에 받음

Readiness

select, poll, epoll, kqueue 계열은 platform마다 API와 scaling 특성이 다르지만 준비된 descriptor를 알려주는 모델로 이해할 수 있습니다. 알림 뒤 실제 read를 수행하며 edge·level trigger 규칙과 non-blocking 설정을 맞춰야 합니다.

Completion

Completion 기반 API는 buffer와 operation을 등록한 뒤 완료 queue에서 결과를 받습니다. 요청 함수가 즉시 반환해도 kernel이 buffer를 계속 사용할 수 있으므로 완료 전까지 operation state를 유지해야 합니다.

선택 기준

Runtime과 framework가 이미 event loop나 async socket을 제공하면 낮은 수준 API를 직접 조합하기 전에 그 lifecycle을 따릅니다. 성능은 API 이름보다 connection 수, active 비율, message 크기, worker 배치와 parsing 비용에 좌우됩니다.

자주 틀리는 점

• Readable 알림이 application message 전체 도착을 뜻하지 않습니다.
• Completion 한 건이 요청한 전체 byte를 처리했다고 무조건 가정하지 않습니다.
• Event loop thread에서 오래 걸리는 CPU 작업을 수행해 다른 connection을 막지 않습니다.
• Close와 cancellation 뒤 늦게 도착하는 event를 안전하게 무시할 수 있어야 합니다.