[완료]스레드를 사용한 select에서 block 상태 빠져나오는 방법

얘기하시는 내용에 약간 모순이 있는 것 같습니다.
모바일 PUSH 서버여서 클라이언트 접속을 오래 가져가야 해서 타임아웃을 길게 설정했는데,
바로 종료할 수 있는 방법을 원하신다는 얘기가 그렇습니다.

기본적으로 접속을 오래 가져가야 하지만 네트워크 단절이 생기는 경우 빠르게 종료시키고 싶으신 건가요?
그렇다면 굳이 타임아웃을 길게 가져가서 할 필요는 없습니다.
네트워크 단절을 체크하는 방법은 몇 가지가 있습니다.

1. 클라이언트가 마지막 보낸 패킷의 시간체크를 통해 설정값을 넘기면 끊겼다고 판단한다. (클라이언트가 주기적으로 패킷을 보내야 함)
    a. 기본적으로 Recv는 thread함수내에 위치하고 루프내에 존재한다.
    b. Recv시 약간 짧은 타임아웃을 주고, 루프를 돌며 경과시간을 누적시킵니다.
    c. 누적 경과시간이 다 된 경우 설정값을 넘긴다면 끊겼다고 판단하고 사용한 자원을 반환하고 루프를 탈출합니다. (결국 쓰레드가 종료되게 됩니다)
2. 실제 패킷을 보내본다 (send시 에러나면 끊기, recv에는 에러가 리턴되지 않습니다)
3. KEEPALIVE 설정을 하는 방법이 있습니다. (TCP 스택 구현에 따라 다르나 보통 지원)

개인적인 추천순서는 1, 2, 3 순입니다.
찾아보시면 일반적으로 KEEPALIVE 설정값을 수정하는건 권장 방법이 아니라고 합니다.

추가적으로 블럭킹 소켓은 SELECT대신에 소켓fd에 setsockopt로 send timout과 recv timeout을 설정할 수 있습니다.

각각의 쓰레드가 하나의 클라이언트만을 담당한다면, (즉, 새로운 연결이 accept()될때마다, 쓰레드를 생성시켜서 그 연결을 할당한다면)

그냥 read()/write() blocking I/O 쓰셔도 될듯한데...왜 select를 사용하시는지 모르겠네요.

어쨋든, 혹시 select() 호출하실 때, exceptfds parameter를 설정안하신건 아닌지 체크해보세요.
또한, FD_ISSET()을 이용하여 체크 할때, exceptfds를 readfds나 writefds보다 먼저 체크하는것이 안전합니다.

그런 자질구레한 버그가 아닌지 체크해보세요.

그리고 pthread_cancel()이 select()을 탈출시키지 못하는 이유는 man페이지에 잘 나와있습니다.

A thread's cancellation type, determined by pthread_setcanceltype(3),
may be either asynchronous or deferred (the default for new threads). 
Asynchronous cancel-ability means that the thread can be canceled at any time
(usually immediately, but the system does not guarantee this).
Deferred cancel-ability means that cancellation will be delayed
until the thread next calls a function that is a cancellation point.
A list of functions that are or may  be  cancellation  points  is  provided  in pthreads(7).

위에 나와 있듯이 deferred가 기본 pthread_cancel type입니다.
Deferred cancel은 취소 요청을 해도 실제 취소는 안하고 예약(??)만 해놨다가
pthreads(7)에 나와있는 cancellation point로 간주되는 함수가 호출될때 정말 해당 쓰레드를 취소하는 방식입니다.

man pthreads 7 하시면 cancellation point로 간주되는 함수목록이 나와있으며
select()는 cancellation point 목록에 없습니다.

man 페이지에 필요한 모든 설명이 나와있으니 차근차근 읽어보시면 이해가 될리라 생각합니다.