[quagga-dev 1358] Re: signal handling breaks gdb on NetBSD - fixed in CVS
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
> 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.
> 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