Signal handler에서 부르는 함수가 전부 asynchronous-signal-safe한 함수인지 확인해 보셨나요? Stevens의 Advanced programming in the unix environment에서 signal 관련 부분을 찾아보시면 리스트가 있습니다.
(혹은 해당 시스템의 man page에서 함수를 하나씩 확인해 보셔도 됩니다. 웬만한 시스템이면 이 함수를 불러도 되는지 안되는지 나와있을 겁니다.)
모든 printf()뒤에 fflush(stdout)이라고 쓰는게 귀찮다면.....
프로그램의 시작부에 <span> setbuf(stdout, 0);</span>
이 한줄을 넣어주면, 라이버리수준의 버퍼링을 없앨 수 있습니다.
즉, stdout의 버퍼(출력버퍼) 크기를 0(널)로 해주기 때문에 버퍼링이 안되고, 즉시 출력하게 됩니다.
...
혹시, 바로 죽지 않는다고 판단한 근거가 출력문입니까?
시그널이 메인코드의 어느 부분 수행중에 발생되었는지를 측정하기는 어렵기 때문에 의구심이 듭니다.
------------------ P.S. --------------
지식은 오픈해서 검증받아야 산지식이된다고 동네 아저씨가 그러더라.
------------------ P.S. --------------
지식은 오픈해서 검증받아야 산지식이된다고 동네 아저씨가 그러더라.
네. printf를 이용한 출력문으로 확인한 것입니다.
시그널이 받아서 실행된 시점이라면 그전에 실행되었던 출력문은 먼저 찍히고,
시그널의 출력문이 찍혀야 하는 것 아닌가요?
(리눅스에서는 그렇게 돌아갔는데...)
메인 함수의 출력문이 나중에 찍혔더라도, 실제로는 시그널 받아서 돌아간 함수의 출력문보다
먼저 실행됬을 가능성도 있다는 말씀이신지...??
printf는 signal handler에서 부르지 못하는 함수입니다
즉, signal handler에서 printf를 불러서 나오는 결과는 믿어서는 안됩니다.
1번이나 2번 fd로 write()를 불러서 확인해 보세요.
printf와는 관계없이 main함수는 돌아가네요.
main함수에서는 message queue내용을 확인하기 위해 loop를 돌던중...
SIGTERM을 받으면 message queue를 없애고, exit를 하게 되는데...
그 이후에 실행되는게 없다면, main함수가 message queue를 못찾는다는 에러는
나오지 않아야 할텐데요. (그냥 종료가 되니...)
에러 메시지가 몇번 나오고 몇번 나고 종료가 되네요.
알송달쏭하네요.
...
Signal handler에서 부르는 함수가 전부 asynchronous-signal-safe한 함수인지 확인해 보셨나요? Stevens의 Advanced programming in the unix environment에서 signal 관련 부분을 찾아보시면 리스트가 있습니다.
(혹은 해당 시스템의 man page에서 함수를 하나씩 확인해 보셔도 됩니다. 웬만한 시스템이면 이 함수를 불러도 되는지 안되는지 나와있을 겁니다.)
출력하실때마다 fflush
출력하실때마다 fflush 함수를 실행하는 것은 어떨까요?
디버깅에 도움이 될것 같습니다.
...
귀차니즘발동시에는.....
모든 printf()뒤에 fflush(stdout)이라고 쓰는게 귀찮다면.....
프로그램의 시작부에
<span> setbuf(stdout, 0);</span>이 한줄을 넣어주면, 라이버리수준의 버퍼링을 없앨 수 있습니다.
즉, stdout의 버퍼(출력버퍼) 크기를 0(널)로 해주기 때문에 버퍼링이 안되고, 즉시 출력하게 됩니다.
------------------ P.S. --------------
지식은 오픈해서 검증받아야 산지식이된다고 동네 아저씨가 그러더라.
------------------ P.S. --------------
지식은 오픈해서 검증받아야 산지식이된다고 동네 아저씨가 그러더라.
댓글 달기