쓰레드가 블럭당했는지 아는 방법이 없을까요?

/proc/<pid>/status 파일을 읽어셔서 "State: " 항목의 값을 확인해 보세요..

awk 쓰시면 편하겠네요.. 그럼!~ 잘되시길

가장 큰 차이는 I/O Completion을 알리는 것이고, select/poll은 I/O Ready
를 알리는 것입니다. 다른 차이는, IOCP의 Thread 사용 및 관리에 있습니다.

IOCP의 가장 큰 목적은 I/O가 빈번히 일어나는 서버가 여러 클라이언트 세션
을 Thread들로 유지함에 따라 발생하는 불필요한 switching cost를 없애기
위한 것이기 때문에, 우선적으로 I/O event 에 따라 thread switching을
하게 됩니다.

위의 방식을 구현하기 위하여 일반적인 Thread Library를 사용하게 되면
switching이 원하지 않는 때에 발생하기 때문에 IOCP 형태를 구현하기가
어렵게 됩니다.

@ IOCP가 무조건 가장 좋은 I/O 처리 구조는 아닙니다. 어디까지나 I/O
가 빈번히 발생하며 동시 세션이 많은 서버에서 좋을 뿐입니다. 어느 수준
이하로 가면 큰 차이가 없으며, 오히려 I/O가 적게 일어나는 서버에서는
Response Time이 커지는 세션이 발생할 수 있습니다.

@ 이러한 Event 기반의 처리 시스템에 대해서는 논문도 있고, 실제로 리눅스
상에서 구현을 하는 경우도 있습니다.

말은 많이 들어보았는데 두개의 방식이 구체적으로 어떤 것이지요?

epoll man페이지에 epoll을 가지고 두 방식의 차이를 설명하고있습니다.

       The epoll event distribution interface is able to behave both  as  Edge
       Triggered  ( ET ) and Level Triggered ( LT ). The difference between ET
       and LT event distribution mechanism can be described as  follows.  Sup-
       pose that this scenario happens :

       1      The file descriptor that represent the read side of a pipe ( RFD
              ) is added inside the epoll device.

       2      Pipe writer writes 2Kb of data on the write side of the pipe.

       3      A call to epoll_wait(2) is done that will return  RFD  as  ready
              file descriptor.

       4      The pipe reader reads 1Kb of data from RFD.

       5      A call to epoll_wait(2) is done.

       If  the RFD file descriptor has been added to the epoll interface using
       the EPOLLET flag, the call to epoll_wait(2) done in step  5  will  hang
       because  of the available data still present in the file input buffers.
       The reason for this is that Edge Triggered event distribution  delivers
       events  only  when  the  status  of a monitored device changes from I/O
       space not available ( state 0 ) to I/O space available ( state 1 ).  In
       the  above  example, an event on RFD will be generated ( supposing that
       the pipe read buffer was empty before ) because of the write done in  2
       ,  and  the event is consumed in 3.  Since the read operation done in 4
       does not consume the whole buffer data ( that is, the condition remains
       I/O  space  available  )  a  transition 0 -> 1 cannot happen in 5.  The
       epoll interface, when used with the EPOLLET flag  (  Edge  Triggered  )
       should  use  non-blocking  file  descriptors to avoid having a blocking
       read or write starve the task that is handling multiple  file  descrip-
       tors.   The suggested way to use epoll as an Edge Triggered ( EPOLLET )
       interface is below, and possible pitfalls to avoid follow.

       i      with non-blocking file descriptors

       ii     by going to wait for an event only  after  read(2)  or  write(2)
              return EAGAIN

       On  the contrary, when used as a Level Triggered interface, epoll is by
       all means a faster poll(2), and can be used wherever the latter is used
       since it shares the same semantics.