Re: signal weirdness fix

["Bart Schaefer" <schaefer@xxxxxxxxxxxxxxxxxxxxxxx>]

On Jan 11,  6:27pm, Zoltan Hidvegi wrote:
} Subject: Re: signal weirdness fix
}
} I investigated this problem a little more and it turns out that Zefram's
} patch in article 2480 was almost the right thing to do.  A terminal signal
} is sent to all processes whose process group is the same as the terminal's
} process group.  When the MONITOR option is set, foreground processes have a
} different process group from the shell so in that case the shell itself
} could not see terminal signals.
[...]
} Now the answer to the `WHY DO WE USE THE RETURN STATUS OF PROCESS GROUP
} LEADER HERE?' question in update_job is clear: a foreground job runs in a
} separate process group when monitor is set so it is quite natural to use
} the status of the leader.

Yes, all of this is exactly right.  For some reason I assumed that this
was common knowledge, or I would have explained it before.

} When MONITOR is not set the shell and the foreground process runs in the
} same process group so both receive the signal.
[...]
} As a result zsh executed the handler twice before this patch.

Now that part *I* hadn't realized.  Having different pgrp behavior when
monitor is off seems a "why bother?" to me.

} Examining the Linux kernel, and the behaviour of ksh and pdksh it seems
} that only SIGINT, SIGQUIT and SIGTSTP needs this special treatment.

Sounds fine.

} I also noticed that on Linux signals received while they are blocked are
} not dropped they are just delayed until they are unblocked.  If that
} happens on all systems we may even leave the current zsh behaviour which
} blocks all signals while it is waiting for foreground process.

Yes, that *is* the way it happens on all systems (unless the system itself
is buggy).  That's why zsh is using sigblock or sighold rather than using a
SIG_IGN handler, when it wants to hold some signals.  Once again, I thought
this was common knowledge (well, common to anyone who knew how to block
signals) and that you had empirical evidence that zsh dropped some signals
in spite of it.

I'm now a bit less puzzled by your long message about how buggy zsh's
signal handling is:  It's not quite as buggy as you thought, just badly
organized and under-commented.

} Although this patch fixes some bad signal problems in zsh I still think
} that it is a big mess and should be ceaned up.  The most important is to
} move trap execution out of the signal handler.  We should only use libc
} calls which are guaranteed to be reentrant on all systems.  This probably
} means that we cannot use malloc() and stdio functions.  Preferably we
} should use system calls only.

This is all absolutely correct.

-- 
Bart Schaefer                             Brass Lantern Enterprises
http://www.well.com/user/barts            http://www.nbn.com/people/lantern