On Mon, Jan 24, 2011 at 4:28 PM, Andy Spitzer <[email protected]> wrote: > Woof! > > On Mon, Jan 24, 2011 at 3:54 PM, Douglas Hubler <[email protected]> wrote: >> 1.) Why have an extra thread spinning when OS will already call your >> shutdown asynchronously for you? > > Well, the extra thread doesn't 'spin', it's always blocked waiting for a > signal. The trick is that THIS thread (and only THIS thread) will ever be > the one that is woken up to deal with the signal. Otherwise, the OS picks a > thread at random, and will interrupt system calls to do it...thus everyone > has to deal with system calls returning EINTR and restarting them. With a > thread doing the work, and it being the only thread that has signals > unblocked, the code can be simplified and made much more robust.
I see now signal is per thread, not for all threads. It got me wondering why every single program in the world wouldn't suffer the same problem because as far as I know, we have no abnormal requirements other than wanting to shutdown gracefully on SIGTERM. So I did some more research and according to this http://www.shrubbery.net/solaris9ab/SUNWdev/MTP/p35.html "All threads in a process share the set of signal handlers set up by sigaction(2) and its variants." So maybe this is better: struct sigaction sig_actions; sig_actions.sa_handler = shutdown_handler; sigemptyset(&sig_actions.sa_mask); sig_actions.sa_flags = 0; int register_sig_action = sigaction(SIGTERM, &sig_actions, NULL); I would really like to use a debugger but also understand why sipXecs daemons are so different than any others. _______________________________________________ sipx-dev mailing list [email protected] List Archive: http://list.sipfoundry.org/archive/sipx-dev/
