select에 대한 의문점... [방준영님이 봐주셨으면 하는 바램이]
소켓 프로그래밍하면
select를 빼놓을수 없을텐데요
아무래도 저는 이놈이 수상했더랍니다
왜 이벤트 갯수을 리턴해서 다시 재 검색을 하게끔 만들었는지요
차라리 이벤트가 발생한 소캣의 인덱스 백터같은걸 넣어서
정확히 이벤트가 발생한 소켓을 인덱스 백터에 리턴 시키고
바로 그놈을들을 처리하면
select에서 리턴해 다시 순차검색으로 이벤트 발생을 검색할 필요가 없을거
같다는 생각이 들었거든요
select 구조상 그렇게 원래 구현할수 밖에 없었다면
poll은 확실히 그렇게 구현했을수도 있을거 같은데
왜 그랬는지 이해가 잘 가지 않거든요
요즘 궁금증이 폭발해 스티븐스의 일루션 볼륨2 TCP/IP 스택에 나온책을
한번 봐봤는데 함수부분에 select부분이 있더군요
그래서 대충 봐봤는데
커널내에서
이벤트를 while로 순차검색한후 이벤트 발생을 FD_SET해주고
이벤트 갯수 카운트를 +1 해주는 방식이더군요
그리고 select 내부에서 이벤트 발생 처리가 끝나면 이벤트 갯수 카운트를
리턴하고요
따라서 select에서 리턴한다음 FD_ISSET으로 이벤트 갯수만큼
다시 순차검색을 하던데
같은 검색을 2번이나 하는거 같았습니다
따라서 IOCP나 kqueue 같은것보다 느리고요
그래서 질문인데 원래 구조상 이벤트가 발생한 인덱스를 리턴하는 방식으로
구현할수 없는것인지
아니면 다른 이유가 있는지 매우 궁금하더라고요
[참 방준영님을 제목에 거론한것은 --; 죄송합니다만은
스티븐스책의 일루션 볼륨2 그책의 소스가 NetBSD거라고 들은거 같아서
커널 개발자분이 잘 아실거 같아 실례를 무릅쓰고 질문 드렸습니다]
답변 좀 부탁드립니다
Re: select에 대한 의문점... [방준영님이 봐주셨으면 하는 바램
select 는 Scalability 문제가 분명히 있습니다. 하지만 자주 사용되는 이유는
편리하기 때문이죠.(특히 GUI 이벤트 관리 부분 같은데서는 충분하죠)
poll을 사용하시는 것은 어떨지요? 그건 select와 같은 문제는 없습니다.
poll도 마찬가지
poll 도 이벤트 갯수수를 리턴합니다
그리고 리턴한다음에도 이벤트를 순차검색으로 재 검색해야합니다
승자는 자기보다 우월한 사람을 보면 존경심을 갖고 그로부터 배울 점을 찾지만 패자는 자기보다 우월한 사람을 만나면 질투심을 갖고 어디 구멍난 곳이 없는지 찾는다.
- 하비스
Re: poll도 마찬가지
엄밀히 말하면 그렇죠 :-) 그러나 poll은 hinting등의 테크닉을 이용해서
확장성의 문제를 많이 개선할 수 있습니다. 그리고 select와 같은 fd의
수 제한도 없지요. 보통은 몇개의 thread나 process를 이용해서 한번에
찾아야 할 fd의 수를 줄이는 방식(state thread)을 많이 사용합니다.
또한 poll 자체도 epoll등과 같은 edge-triggered 방식의 구현을 통해서
문제가 해결이 되는 것으로 알고 있습니다.
아, 제가 드리는 답변이 틀리면 어떡하나 가슴이 조마조마하네요. 8)
아, 제가 드리는 답변이 틀리면 어떡하나 가슴이 조마조마하네요. 8)
select나 poll을 왜 그렇게 이상하게 만들었냐하면, 이 API들을 stateless하게 만들어야 했기 때문입니다. 왜 stateless하게 만들 수 밖에 없었는지는 저도 사실 모르겠습니다. 유추를 해보면, 만약에 이것들을 stateful하게 만들려면 커널에서 해당 디스크립터에 관한 표를 메모리상에 항상 할당해 놓고 있어야 하잖아요. 그러면 리스트들을 최신 상태로 유지하는데 드는 비용도 증가하고, 거기다 메모리까지 많이 먹지요. 요즘과 달리 그때(90년대초?)는 메모리가 꽤 비싸던 시절이었고, 더군다나 커널 메모리는 페이지 아웃도 안되니까 더더욱 비용이 높지요. 또 장치쪽에서도 자체 디스크립터 리스트를 유지하고 있어야 하는데 그럼 고려해야할 부분이 늘어나고요(힌팅처럼). 이러나 저러나 stateless 방식으로 만드는 게 싸게 먹혀서 그렇게 만든 듯 합니다. 성능은 좀 희생할지언정 말이죠.
그리고 요즘에 kqueue같은 게 멀쩡하게 잘 동작하고 있는 것으로 보아도 반드시 select나 poll처럼 만들 필요는 없다는 것이 증명되었다고 봅니다.
[쓰고 나서 다시 생각해 보니 그 시절에는 서버 동시 접속 10000건 같은 건 상상도 못했을 일이라 굳이 시스템을 복잡하게 만들 필요가 없었던 것 같네요. 인터넷의 대중화가 select와 poll을 구닥다리로 만들었단 생각이 듭니다. 8)]
답변 감사 드립니다 ...
제 의문을 풀어주셔서 감사드립니다
저는 왜 이렇게 만들수 밖에 없었는지 매우 궁금했거든요
한마디로 옛날에는 ...... 그럴수 밖에 없었다는 말씀이네요
그런데 인터넷 인구가 폭발하면서
충분히 개선할만한 내용임에도 불구하고....
이것을 대처할만한 마땅한 unix 표준이 나오지
않고 있다는것이 매우 불만인데.....
BSD쪽은 그래도 --; 준영님 같은 능동적인? D 커널 개발자들이
많아서 인지 kqueue[사실 정확한 작동은 모르나... --;] 라는것이
나왔는데 다른 유닉스나 리눅스같은 경우 select를 대처할만한
마땅한 poller가 존재 하지 않는 다는 사실이 놀랍더라고요
리눅스는 이제야 epoll 이니 뭐니 하고 있고...[시험중이죠?]
다른 poller가 존재해도 select보다 크게 나을봐가 없고
윈도우에서도 IOCP라는 놈이 있는데 네트워크쪽에서
큰핵을 차지 하고 있는 유닉스가 kqueue같은 표준하나 없다는것에
놀랍기만 하네요 --;
아무리 생각해도 select 내부를 간단히 --; 살펴본 결과로는
준영님 같은 분이 ... 좀만 손대면 금방 제가 위에서 말한것처럼
고칠수 있을거 같다는 생각이 들었거든요
select는 아무래도 구조상 힘든거 같으니 , 그냥 poll에 배열 포인터
하나와 배열 카운트를 더 넣게 만들어서 이벤트가 발생한 인덱스를 담도록 만들면
좋지 않을까 싶더라고요
그래서 POSIX 표준으로 나와줬으면 하는 바램두 --;
그냥 유닉스가 MS의 개발 마인드에 뒤쳐친거 같아 아쉬워서 품념한번 늘어나봤습니다 --;
[ 윈도우에서만 플밍하다가 한달전쯤에 처음 리눅스 플레폼에 손을 대서 그런지 제가 몰라서 그럴수도 있습니다 --;]
승자는 자기보다 우월한 사람을 보면 존경심을 갖고 그로부터 배울 점을 찾지만 패자는 자기보다 우월한 사람을 만나면 질투심을 갖고 어디 구멍난 곳이 없는지 찾는다.
- 하비스
말씀 감사합니다만, kldp bbs에는 실무에서 오랜 경험을 쌓으신 쟁쟁
말씀 감사합니다만, kldp bbs에는 실무에서 오랜 경험을 쌓으신 쟁쟁한 전문가분들이 많이 계시므로 그분들께서 저보다 이 문제에 관해 훨씬 잘 알고 계시리라 생각합니다. 8)
저는 반대로 요즘 거의 95% 윈도 프로그래머로 전향(?)했는데, 예상보다 그쪽이 잘 되어 있는 걸 느낍니다. 마이크로소프트가 괜히 세계를 주름잡는 게 아니었구나라고 할까요. 아무튼 좋은 기능을 쏙쏙 뽑아다 오픈 소스 유닉스쪽에도 도입을 했으면 좋겠습니다. 8)
댓글 달기