[quagga-dev 1362] Re: signal handling breaks gdb on NetBSD - fixed in CVS
paul at clubi.ie
Thu Jul 15 12:41:38 BST 2004
On Thu, 15 Jul 2004, Greg Troxel wrote:
> without blocking, we need to be careful about ordering, esp. with
> two variables,
Yep. That's why the global caught is cleared immediately compare and
not checked again.
> so this could use comments.
> I had meant to check the master flag at return from select to get
> promptness, rather than avoiding the for loop over memory. IMHO
> it's annoying to send a SIGTERM and have it take 2 seconds to exit;
> there is no good reason why it shouldn't be prompt. This has
> actually caused me grief - I have a script to send sigterms, wait
> and then restart everything. Daemons were failing to restart
> because the old one hadn't exited yet.
hmmm.. Surely your script is broken?
But yes, I guess we could change it to run the non-signal-context
'signal handlers' on EINTR. We dont need any master flag in that case
btw, EINTR from select() should be enough to tell us a signal occured
> I don't see that it is safe to assume sig_atomic_t can be
> incremented, unless POSIX says so,
It does apparently. I cant find an authoritative reference. However,
I do find many second-hand statements saying it is defined to atomic
by POSIX, and my Stevens APUE book says the same.
But I've not found any authoritative POSIX text or quotes from the
standard to say so.
> but perhaps all we care about that is that it ends up non-zero.
> We could assign 1 to it instead, since we aren't counting, and that
> seems safer, not needing a load/store on risc architectures or a
> RMW cycle on CISC.
Ah, good point.
> I'd leave the blocking code ifdef 0 for now; we may need to add a
> configure test to enable it later.
Paul Jakma paul at clubi.ie paul at jakma.org Key ID: 64A2FF6A
warning: do not ever send email to spam at dishone.st
No use getting too involved in life -- you're only here for a limited time.
More information about the Quagga-dev