Readiness APIs

select·poll은 전체 후보를 보고, epoll·kqueue는 준비 이벤트를 돌려준다

대규모 연결에서 차이는 등록과 대기의 위치에서 난다. 매번 전체 후보를 넘기고 훑는 방식과, 관심 fd를 커널에 등록해두고 준비된 이벤트만 받는 방식은 반복 비용이 다르다.

select는 fd_set 복사와 FD_SETSIZE 제한이 걸린다

poll은 고정 비트셋 제한은 줄지만 배열 순회 비용은 남는다

epoll/kqueue는 등록 후 준비 이벤트 중심으로 받는다

질문

select

poll

epoll / kqueue

관심 fd 전달

매 호출 fd_set 복사유저 공간에서 커널로 비트셋을 다시 전달한다.

매 호출 배열 전달pollfd[]를 넘기며 fd 수만큼 후보가 생긴다.

한 번 등록 후 유지epoll_ctl 또는 kevent로 관심 대상을 관리한다.

대기 중 검사

전체 후보 확인준비된 fd가 적어도 후보 집합 전체가 반복 비용이 된다.

전체 배열 확인FD_SETSIZE는 피하지만 조용한 fd까지 배열에 남아 있다.

준비 이벤트 중심커널이 준비 목록을 만들고 대기 호출은 이벤트 배열을 받는다.

반환 뒤 작업

앱이 다시 찾음어느 fd가 준비됐는지 집합을 확인해야 한다.

revents 확인각 항목의 revents를 보며 처리한다.

이벤트 배열 순회돌아온 ready 이벤트만 순회하고 콜백/처리를 실행한다.

select / poll

fd 4조용하지만 검사

fd 7ready

fd 12조용하지만 검사

epoll / kqueue

registeradd / modify / delete로 관심 이벤트 관리

wait준비된 이벤트 배열 반환

Event loop

accept새 연결 등록

read/writenon-blocking 처리

backpressure너무 많이 쓰지 않게 조절

FD 제한select는 구현상 FD_SETSIZE 제한에 걸리기 쉽다.

복사 비용select/poll은 호출마다 관심 집합을 다시 넘긴다.

Ready 중심epoll/kqueue는 준비 이벤트 개수에 더 민감하다.

처리 비용반환 후 콜백, 파싱, 쓰기 버퍼 비용은 여전히 남는다.

핵심: epoll/kqueue가 마법처럼 CPU 비용을 없애는 것은 아니다. 조용한 연결을 매번 훑는 비용을 줄이고, 준비된 이벤트 중심으로 서버 루프를 구성하게 해준다.