On Mon, 2009-03-23 at 16:37 +0000, Dave Martin wrote: > Anyway, if there is a problem with the existing code, it would be that > the signal handler can interrupt the code in nih_signal_poll(), after > a given element in signals_caught is checked, but before the elements > of signals_caught[] are reset to zero. Could this cause a signal to > be lost? > If the signal arrives between the time that the handler is checked for (and maybe run for the last time) and the time that the caught counter is reset, yes - the signal will be lost and the handler will not be run again.
That's definitely a bug, and it's even in my known bugs list -- hell, even the comment in nih_main_loop() actually tries to claim we don't do what we end up doing. All this stuff has been reworked for the next version of Upstart, which uses signalfd() to solve the problem. HOWEVER it is worth noting that Upstart ignores SIGCHLD anyway, other than to wake up the main loop. Since the interrupt pipe is cleared before any processing, the signal is always guaranteed to do that and will never be lost. We always call waitid() every time through the main loop, so I don't believe it's possible for the death of a child to be missed or even handling to be delayed. So it's not causing this problem... Scott -- Scott James Remnant [email protected] -- init stops respawning terminal logins after while https://bugs.launchpad.net/bugs/347205 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list [email protected] https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
