traditional unix signal은 queueing이 불가능합니다만, psjcap님께서 링크 거신 곳에도 나오는 RTS(Real-Time Signal)은 queueing을 지원합니다.
다행히 대부분의 UNIX에서 RTS를 지원하고, 리눅스 또한 RTS를 지원하므로 RT용 signal들을 사용하시면 됩니다. (RT용 signal은 kill -l 커맨드로 확인해볼 수 있습니다.). 다만, kill() 등을 사용하여 signal을 보내면 traditional 방식으로 처리하므로, sigqueue() 등을 사용하셔야 합니다.
그리고 SIG_BLOCK을 해주는 이유는, 아마 sigwaitinfo()를 하기 전에 signal이 발생하여 프로세스가 원치 않는 행동을 하는 것을 막기 위함이 아닐까 합니다. (시간이 없어서 코드를 자세히 읽어보진 못했습니다.)
여러가지로 thread와 signal (특히 traditional signal)을 같이 운용하는 것은 고달프고 portability에도 좋지 않습니다. 또한 signal은 단순히 신호이고, 부가적인 데이타나 정보등을 같이 보내기 어렵기 때문에, 전용 messaging system을 구현하시는 것이 좋을 것으로 생각됩니다. 굳이 사용해야 한다면 reliability를 보장 해주는 RTS를 사용하시는 것이 좋습니다.
현재 aio_read, aio_write 함수를 이용해서 코딩 중입니다..
aio_read, aio_write함수로 입출력이 완료되면..
SIGNAL을 전송할 수 있구요..
물론 SIGNAL + 추가적인 데이타를 보낼 수 있어서 매우 편리하더군요..
코딩도 매우 깔끔해지고..
위에 질문한 내용등에 대해서 나름데로 연구해서 얻은 결론은..
sigwaitinfo 함수는 pending 된 시그날 값을 읽는 함수더군요..
그래서 pending되도록 BLOCK을 시킨 것 같습니다..
JOINC에 있는 소스를 보면 MAIN THREAD에서 sigprocmask를 사용하였는데..
sigprocmask는 thread에서 상속되지 않는다고 하는군요..
아마도 상속시키지 않으려고 MAIN THREAD에서는 sigprocmask를 사용한 듯 합니다...
pthread_sigmask
pthread_sigmask() 로는 안되나요?
만약 모든 signal을 하나의 thread에서 처리하겠다고 하면, signal handling thread를 제외한 모든 thread들에서 pthread_sigmask()를 사용하여 모든 signal들을 masking하면 됩니다.
이렇게 했는데 잘 안된다는 것이라면 저도 잘 모르겠군요. 적어도 리눅스에서는 위 방법을 사용하여 특별히 문제된 적은 없습니다. :)
signal이 쌓이게 하려면..
signal이 동시에 발생하더라도 queue에 쌓이게 하고 싶은데요..
그럴려면 어떻게 해야 하나요..??
제 생각엔 main에서 BLOCK하고..
THREAD에서 UNBLOCK 시킨 후..
sigwaitinfo 함수로 대기했다가 받으려고 하는데..
만약에 다른 signal 처리 도중이라 못 받게 된다면 어떻게 되는건가요..??
그리고 joinc 사이트에 밑에 강좌를 보았는데요....
http://www.joinc.co.kr/modules.php?name=News&file=article&sid=137
THREAD에서 SIG_UNBLOCK을 해주는게 아니라..
오히려 SIG_BLOCK을 해 주는데 이유가 무엇일까요..??
signal queueing
traditional unix signal은 queueing이 불가능합니다만, psjcap님께서 링크 거신 곳에도 나오는 RTS(Real-Time Signal)은 queueing을 지원합니다.
다행히 대부분의 UNIX에서 RTS를 지원하고, 리눅스 또한 RTS를 지원하므로 RT용 signal들을 사용하시면 됩니다. (RT용 signal은 kill -l 커맨드로 확인해볼 수 있습니다.). 다만, kill() 등을 사용하여 signal을 보내면 traditional 방식으로 처리하므로, sigqueue() 등을 사용하셔야 합니다.
그리고 SIG_BLOCK을 해주는 이유는, 아마 sigwaitinfo()를 하기 전에 signal이 발생하여 프로세스가 원치 않는 행동을 하는 것을 막기 위함이 아닐까 합니다. (시간이 없어서 코드를 자세히 읽어보진 못했습니다.)
여러가지로 thread와 signal (특히 traditional signal)을 같이 운용하는 것은 고달프고 portability에도 좋지 않습니다. 또한 signal은 단순히 신호이고, 부가적인 데이타나 정보등을 같이 보내기 어렵기 때문에, 전용 messaging system을 구현하시는 것이 좋을 것으로 생각됩니다. 굳이 사용해야 한다면 reliability를 보장 해주는 RTS를 사용하시는 것이 좋습니다.
답변감사합니다..
답변 주셔서 감사합니다..^^"
현재 aio_read, aio_write 함수를 이용해서 코딩 중입니다..
aio_read, aio_write함수로 입출력이 완료되면..
SIGNAL을 전송할 수 있구요..
물론 SIGNAL + 추가적인 데이타를 보낼 수 있어서 매우 편리하더군요..
코딩도 매우 깔끔해지고..
위에 질문한 내용등에 대해서 나름데로 연구해서 얻은 결론은..
sigwaitinfo 함수는 pending 된 시그날 값을 읽는 함수더군요..
그래서 pending되도록 BLOCK을 시킨 것 같습니다..
JOINC에 있는 소스를 보면 MAIN THREAD에서 sigprocmask를 사용하였는데..
sigprocmask는 thread에서 상속되지 않는다고 하는군요..
아마도 상속시키지 않으려고 MAIN THREAD에서는 sigprocmask를 사용한 듯 합니다...
그럼 좋은 하루 되셔요..^^"
댓글 달기