Real time signal로 프로그램 작성에 관하여
c/c++에 적응하는게 좀 힘들군요,..
rts에서는 특정 socket fd에서의 event가 발생하면
그 event에 대해 signal을 kernel이 발생시켜서 handler를 호출하는걸로
이해하고 있습니다
근데 그 io event 라는 것이
socket의 경우, acceptable, connectable, readable, writable 이고,
readable 이나 writable 되었다고 하더라도
그 socket 에 대해 주구장창 계속 readable 하거나 writable
할수 있다는 얘기는 아니죠?
다음 joinc에 있는 예제가 좀 이해가 안가는 데요..
http://www.joinc.co.kr/modules/moniwiki/wiki.php/article_Real_Time_Signal2
accepted된 socket에 대해서
RTS 로 signal을 받아서 send_chat_msg 이 함수를 호출 하도록 되어 있는데
이 send_chat_msg 에서
단순히 write 하면 거기 속에 있는게 다 보내졌는지 안보내졌는지
알수 없는것 아닌가요?
결국, RTS 같은걸 사용하기 위해선
각각의 accepted socket에 대해서
일종의 state machine 개념이 있어야 하고, input, output에 대해
buffer (Queue) 가 반드시 있어서
readable, writable 할때마다 그 버퍼속의 내용을 차례대로
읽거나 써야 한다는 말인가요? 제 이해가 맞는지요?
예제가 조금 잘못된 것이 아닌가 싶은 생각이 드는군요. I/O처리를 시그
예제가 조금 잘못된 것이 아닌가 싶은 생각이 드는군요. I/O처리를 시그널로 하건 select/poll로 하건 이런 내용과는 관계없이 read/write에서는 "당연히 & 언제나 & 꼭" 리턴값 검사를 해야 합니다. 그렇지 않으면 언젠가는 문제가 생깁니다.
(네트웍을 통해서이건 로컬에서건) I/O와 관련된 문제는 모든 유닉스 프로그래밍을 통틀어 가장 골치아프고 어려운 문제 중의 하나가 아닐까 생각합니다. 이미 보셨겠지만 Stevens아저씨의 명작은 바로 이 순간에도 위력을 발휘하지요. 제가 가지고 있는 한권짜리 구판에는 이 내용이 없다는 것이 심히 유감스럽지만.. :<
ps. asynchronous I/O를 위해 사용하는 시그널을 RTS로 부른다는 사실은 오늘 처음 알게 되었군요. 원래 RTS라는 표현을 사용하나요? 오히려 저는 이것을 기존 시그널의 인터페이스상 reliability가 떨어지기 때문에 4.3BSD에서 도입하기 시작한 새 implementation의 일종이라고 이해하고 있었는데요.
댓글 달기