Re: Is wait not interruptable?

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

Peter Stephenson wrote:
> The first is that the subshell itself (the stuff in parentheses) doesn't
> get killed because it's waiting for the child process.  This seems to be a
> feature of SIGTERM.  If you "setopt trapsasync" or send a different signal
> such as SIGHUP it does get killed.  I'm not really sure why SIGTERM is
> different.

I got a chance to look at the code in more detail.

It's not SIGTERM that's different, it's SIGHUP.  The code is:

    if (isset(TRAPSASYNC)) {
	sigemptyset(set);
    } else {
	sigfillset(set);
	sigdelset(set, sig);
#ifdef POSIX_SIGNALS
	sigdelset(set, SIGHUP);  /* still don't know why we add this? */
#endif
	if (wait_cmd)
	{
	    /*
	     * Using "wait" builtin.  We should allow SIGINT and
	     * execute traps delivered to the shell.
	     */
	    int sigtr;
	    sigdelset(set, SIGINT);
	    for (sigtr = 1; sigtr <= NSIG; sigtr++) {
		if (sigtrapped[sigtr] & ~ZSIG_IGNORED)
		    sigdelset(set, sigtr);
	    }
	}
    }

So there's not really any mystery about how it behaves, only why it's
the way it is.  POSIX is fairly light on what to do with signals:
http://www.opengroup.org/onlinepubs/009695399/utilities/xcu_chap02.html#tag_02_11

TRAPSASYNC was really introduced, as the name suggests, to affect trap
execution (see second paragraph of the section in the URL), not the
point at which the signal is delivered to the shell, but in practice it
does the former by altering the latter.  The may be a case for always
handling the signal immediately and altering the code only to delay any
traps.  But I'm still not sure why it's done the way it is.

-- 
Peter Stephenson <p.w.stephenson@xxxxxxxxxxxx>
Web page now at http://homepage.ntlworld.com/p.w.stephenson/