소켓 IO

둘다 비동기에다 버퍼를 커널모드에 등록하고(이 부분은 정확한지는 모르겠지만

일단 등록한 버퍼에다 바로 쓰지요.)

둘다 WORK THREAD모델을 써야 될듯 합니다.

지금 저도 IOCP모델은 만들어 봤고 EPOLL 모델을 만들고 있는데 EPOLL

도 시퀀스로 짜면 처리 하기 힘듭니다. ACCEPT 모듈과 클라이언트 와의

통신 모듈을 따로 처리 해야 될듯 합니다. IOCP처럼 EPOLL도 대기 모두가

있기 때문입니다. 물론 타임을 정해 줄수 있지만 효율적인 처리를 하기 위해서

서는 멀티 쓰래드 모델로 가야 된다고 생각합니다.

그리고 EPOLL은 SELECT 와 전혀 틀립니다. SELECT는 어떤 SOCKET 에서

발생했는지 알수가 없습니다. 하지만 EPOLL은 등록할 버퍼에 소켓 디스크립터

를 같이 멤버로 가지고 있기 때문에 알수가 있는것이고 FOR 문을 도는 것은

감지할 때 그만큼의 감지 일어난 갯수를 리턴해야 되기 때문에 당연히 처리

해줘야 되는 부분이라고 생각합니다. IOCP는 쓰래드 관리를 맡아서 해주니까

편한 점은 있죠. EPOLL은 저희가 구현 해야 될듯 하구요...

답변에서 틀린 점이 있으시면 가차 없이 태클 걸어주시기 바랍니다.

^___^;

multiprocessor가 아닌 경우라면, 위의 경우에서 multithread model
그다지 효율적이지 않을 것 같습니다.
특히나 HTTP server와 같은 경우라면 acceptor 와 통신 부분을 따로 떼서
처리할 경우 extra context-switching을 유발하게 되어 성능상 제약을
주게 될 것 같습니다.

무슨관계가 있다는건지 궁금하군요 :)

위에 분들 말씀처럼

non_blocking I/O

IO_multiplexing

signal-driven I/O

asynchronous I/O

모두 다릅니다. 특히 신호에 의한 입출력과 비동기와 비슷하면서도

다르죠. 입출력 동작의 시작과 완료시점에 대한 차이점으로 구분하는

걸로 알고 있습니다.

user thread가 library scheduler를 갖는다는 보장이 있습니까?
posix thread 에 scheduler implementation의 정의가 있나요?

실제로 앞으로 linux thread를 dominant 할 것으로 생각되는(최소한 제 생각으로는),
NTPL 의 경우도 초기 initial draft에서는 M-N을 언급했었지만,
최종 design은 1-1 을 선택하고 있습니다.
그리고 이는 꽤 괜찮은 성능을보여주는 것도 사실입니다.
(물론 kernel의 성능향상도 포함됩니다. O(1) scheduler 같은 경우..)

그렇다고 하더라도 "제가 예로 든" 요청이 잦은 HTTP 서버 같은 경우라면,
extra context switching은 좋지 않다고 봅니다.
하나의 request에 대해 context switching이 없이 처리하는 것이 훨씬
나은 선택이라고 봅니다.

listener socket을 epoll에 넣으면 어떨까요?

간단한 논쟁이긴 하지만, 제 생각에는 single processor의 성능을
잘 발휘할 수 있는 것은 multi-thread가 아니라, async action을 잘 처리하는
single thread라고 봅니다. 이는 multi processor에도 마찬가지라고 봅니다.
processor 갯수 정도 만큼의 async action을 잘 처리하는 thread 가 서버에
적합하다고 생각합니다. 논란의 여지는 많겠지요 =)

어차피 어떤 형식을 쓰더라도 epoll이든 IOCP이든간에
서버모델에서 이들이 차지하는 오버헤드는 극히 작습니다.
또한 한 서버의 한 프로세스에서 일반적으로 몇천이상의 접속을 가져가는 것보다 프로세스를 쪼개는 것이 더 좋습니다.

따라서 어느것이 더 많은 오버헤드가 있다 없다라고 하는 것은 좀 논의 밖이 아닐까 생각됩니다. 사실 epoll정도 되면 속도면에서 그다지 손해보는 것은 거의 없습니다.

일반적으로 서버모델에서는 윗에 어떤 분도 말씀했듯이 접속을 받는 부분, accept 를 처리하는 부분, 실제 socket buffer 로부터 데이터를 읽어서 처리하는 부분을 보통 따로 떼어내어 멀티 쓰레드로 돌림으로서 지연을 최대한 줄이고, 데이터트랜잭션 처리구간을 조금이라도 빠르게 하는게 더 중요한게 됩니다. select네 poll이네 epoll, kqueue 냐? 혹은 MS의 IOCP 냐? 하면서 성능비교하는 것은 흥미위주일뿐 사실상 그게 주가 되지는 않습니다.