Re: localtraps and signal handling on NetBSD

[Peter Stephenson <pws@xxxxxxx>]

Vincent Stemen wrote:
> # --------- <test script> -----------
> sigterm1()
> {
>     trap 'echo "-- sigterm2 --"' TERM
>     echo "sigterm1(): sending SIGTERM"
>     kill -TERM $$
>     trap sigterm1 TERM
>     sleep 1
> }
> 
> trap sigterm1 TERM
> 
> echo
> echo "main: sending SIGTERM"
> kill -TERM $$
> echo "main: sending SIGTERM"
> kill -TERM $$
> # --------- </test script> -----------
>
> Here is the output of zsh and bash.
> 
> <zsh>
> main: sending SIGTERM
> sigterm1(): sending SIGTERM
> sigterm1(): sending SIGTERM
> sigterm1(): sending SIGTERM
> sigterm1(): sending SIGTERM
> ... continues forever
> </zsh>

Yes, I can see this, but this isn't the same example I was looking at
when I saw different behaviour from you.

What I think is happening here is that signals *are* being queued.  Then
the SIGTERM is delivered after sigterm1 has returned, at which point
sigterm1 has been reinstalled as the signal handler, so gets called
again ad infinitum.

In this case bash and zsh are actually trying a bit harder to do the
right thing, at least as far as safety of the execution environment is
concerned.  Not queueing signals can cause significant reentrancy
problems.  However, it may be possible to unqueue signals temporarily at
some point.  That's still not trivial; the code's currently not written
to allow that, since as I said before the queue/unqueues are all nested
and you need to have some clue about the environment to decide whether
temporarily unqueuing is safe.  Possibly some queue/unqueue pair can be
moved deeper into the code, leaving some points at which signals will be
handled, but that's not trivial either.

-- 
Peter Stephenson <pws@xxxxxxx>                  Software Engineer
CSR PLC, Churchill House, Cambridge Business Park, Cowley Road
Cambridge, CB4 0WZ, UK                          Tel: +44 (0)1223 692070


**********************************************************************
This email and any files transmitted with it are confidential and
intended solely for the use of the individual or entity to whom they
are addressed. If you have received this email in error please notify
the system manager.

**********************************************************************