From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 4140 invoked from network); 11 Jan 1997 18:38:03 -0000 Received: from euclid.skiles.gatech.edu (list@130.207.146.50) by coral.primenet.com.au with SMTP; 11 Jan 1997 18:38:03 -0000 Received: (from list@localhost) by euclid.skiles.gatech.edu (8.7.3/8.7.3) id NAA02266; Sat, 11 Jan 1997 13:45:40 -0500 (EST) Resent-Date: Sat, 11 Jan 1997 13:45:40 -0500 (EST) From: "Bart Schaefer" Message-Id: <970111105041.ZM1400@candle.brasslantern.com> Date: Sat, 11 Jan 1997 10:50:41 -0800 In-Reply-To: Zoltan Hidvegi "Re: signal weirdness fix" (Jan 11, 6:27pm) References: <199701111727.SAA01061@hzoli.ppp.cs.elte.hu> Reply-To: schaefer@nbn.com X-Mailer: Z-Mail (4.0b.820 20aug96) To: Zoltan Hidvegi Subject: Re: signal weirdness fix Cc: zefram@dcs.warwick.ac.uk, zsh-workers@math.gatech.edu MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Resent-Message-ID: <"bgiFS2.0.LZ.J_zro"@euclid> Resent-From: zsh-workers@math.gatech.edu X-Mailing-List: archive/latest/2777 X-Loop: zsh-workers@math.gatech.edu Precedence: list Resent-Sender: zsh-workers-request@math.gatech.edu 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