On Fri, Nov 16, 2007 at 02:49:41PM -0800, David Bustos wrote: > Well I didn't find a definitive statement that signals are deferred > while a process is stopped and delivered when it is restarted, but > I have observed svc.startd sometimes exiting after pstop/kill/prun and > sometimes not on my snv_69 desktop. And when it doesn't, > "echo finished::print | mdb -p `pgrep startd`" reports 0x1, which > indicates that the signal handler was indeed executed, but the main > thread was not awoken. So I think that when svc.startd is started > normally, the kernel always selects the main thread to deliver signals > to, but pstop'ing and prun'ing will sometimes rearrange things so that > the kernel chooses another thread. In which case the bug still valid.
Thread selection for signal delivery is not deterministic when multiple threads could catch a given signal. You have to block signals of interest in the main thread before starting other threads so that the new threads inherit the parent's signal mask, then the one thread that you want to get signalled can use sigwait(2) to wait for a blocked signal. Alternatively you can use the old trick of polling on a pipe such that the signal handler writes to the other end of the pipe, or use event ports and have the handler send a user defined event to a port. Nico --
