[quagga-dev 1358] Re: signal handling breaks gdb on NetBSD - fixed in CVS

Paul Jakma paul at clubi.ie
Wed Jul 14 15:06:07 BST 2004

On Wed, 14 Jul 2004, Greg Troxel wrote:

> I'm not sure it matters - all the handler does is set caught, and 
> the real handler will run at next timer interval.  So it won't 
> speed up processing.

No i mean the non-sigcontext handler, sig->handler() - not the stub 
handler which sigevent sets up and is called in signal context. 
sig->handler might _do_ anything (whole reason for existence of 
sigevent is that some daemons were doing things like running long 
long shut down paths in sigcontext, calling non-sigcontext-safe 
library functions).

> One possibly useful thing to do is to have a master 'signal handler 
> runnable' flag that gets set by any signal, and have the select 
> loop run the signal handler dispatch when that's set on return from 
> select.  That would make signal handling prompt while keeping the 
> safety properties we have now.

Good point.

> I don't see the need to make the locking more fine-grained, since the
> code we avoid deferring isn't the actual handler.

it is, sig->handler() is pointer to god knows what code path.

Paul Jakma	paul at clubi.ie	paul at jakma.org	Key ID: 64A2FF6A
 	warning: do not ever send email to spam at dishone.st
Are you ever going to do the dishes?  Or will you change your major to biology?

More information about the Quagga-dev mailing list