kqueue와 달리 epoll은 왜 fd에 대한 event 추적이 불가능한가

c++로 nginx와 비슷하게 동작하는 웹서브를 만들면서 의문이 생겼다.

난 kqueue를 사용해 fd에 대한 read write를 kevent에 등록해서 socket, 정적 파일에 대한 I/O작업 buffer_size로 잘라 전부 event로 관리했다. (subject 규칙에 file에 대한 I/O는 멀티플렉싱 event를 통해서만 가능하다고  쓰여 있다)

파일을 read 할 때도 socket read 할 때와 동일한 buffersize만큼 읽어 와서 제일 오래 걸리는 I/O작업을 분할하는 데 의의가 있다고 생각했다.
buffersize가 100일 때 파일의 크기가 10000이고
그 파일을 읽는 작업을 이벤트 하나에서 처리해 버리면(ex. 반복문 안에서 eof까지 무한 read) 100번으로 잘게 쪼개지지 않아 다른 클라이언트들이 그 부담을 떠안게 된다.

그래서 공-평하게 buffer-size(1024)로 잘랐다.

 

그런데 다른 카뎃분이 해당 정적 파일에 대한 nonblock I/O처리에 대해 질문을 올리셨는데, 답글로 토론하다 보니 석연치 않은 구석이 생겼다. 일단 kqueue에서도 정적 파일에 대한 fd를 nonblock처리해도 실제로는 block으로 동작하고, epoll에서는 아예 fd에 대한 event를 받으면 에러를 띄워버린다고 한다(https://www.remlab.net/op/nonblock.shtml). 결국 멀티플렉싱관련 함수를 설계한 사람은 정적파일에 대한 event를 nonblock으로 처리하지 않길 원한다는 건데, 이에 대한 많은 의견들이 오고 갔다. socket과 달리 일반 파일은 block 될 여지가 없어서(무조건 읽을 수 있으니) 그렇다는 의견이 다수였고, 내 의견은 커널 모드로의 컨텍스트스위치 비용 때문이다였다.

 

사실 내가 처리한 방식인 10000짜리 파일을 buffersize 100으로 잘라 읽으면 client connection이 많고 event들이 많은 상황에선 엄청나게 오래 기다리게 된다. 너무 공평함에 집착하다 보니 비효율적인 것이다... 너무 극단적이긴 하지만;

 

kqueue epoll 설계한 사람만이 알겠지만 위 두 이유 때문이지 않을까 싶다.

 

42seoul의 마지막 c++과제인 webserv가 끝났다..!

이제 전부터 갈망하던 웹개발 스택 공부를 해야겠다 씐난다~