Re: Possible signal handling issues

[Peter Stephenson <p.w.stephenson@xxxxxxxxxxxx>]

On Thu, 2 Jan 2014 21:55:05 +0000
Peter Stephenson <p.w.stephenson@xxxxxxxxxxxx> wrote:
> Consequently, this looks to me like some intrinsic race that happens to
> be particularly reproducible in the "wait" case.

Consider, for example:

sleep 20 &
TRAPINT() { set -x; kill -INT $$; sleep 1 }
wait

Now I get the output from the trap as long as I wait for the sleep to
finish, but the function doesn't exit.  I presume that's because SIGINT
is now arriving while the trap is still running (and the fact that ^C
within a second has no effect is consistent).  Given that traps are
intrinsically asynchronous, that's not necessarily related to a bug in
the shell.  However, it's making the analysis even more complicated.

I further note that if I run sleep 20 normally in the foreground
(without the sleep in the trap) I get:

TRAPINT:0:> kill -INT 25339
TRAPINT:0:> kill -INT 25339

exactly twice.  That was consistent with zsh -i with an fg, but not
setopt monitor with an fg.  I'm guessing (but it's just a guess) that
the first time the trap exits quickly so the INT hits just afterwards
but the second time there's enough processing around that the signal
arrives before the trap has exited (or more precisely before the
internal framing of the trap has finished).

I'm getting less convinced this is anything more than a
you-only-have-yourself-to-blame oddity...

pws