From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from euclid.skiles.gatech.edu (list@euclid.skiles.gatech.edu [130.207.146.50]) by melb.werple.net.au (8.7.5/8.7.3/2) with ESMTP id LAA27641 for ; Fri, 19 Jul 1996 11:17:02 +1000 (EST) Received: (from list@localhost) by euclid.skiles.gatech.edu (8.7.3/8.7.3) id VAA13211; Thu, 18 Jul 1996 21:11:13 -0400 (EDT) Resent-Date: Thu, 18 Jul 1996 21:11:13 -0400 (EDT) From: Zoltan Hidvegi Message-Id: <199607190108.DAA02567@hzoli.ppp.cs.elte.hu> Subject: Re: Blocking child signals To: schaefer@nbn.com Date: Fri, 19 Jul 1996 03:08:33 +0200 (MET DST) Cc: zsh-workers@math.gatech.edu In-Reply-To: <960714230242.ZM2685@candle.brasslantern.com> from Bart Schaefer at "Jul 14, 96 11:02:38 pm" X-Mailer: ELM [version 2.4ME+ PL17 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Resent-Message-ID: <"AMRyM3.0.IE3.m2kxn"@euclid> Resent-From: zsh-workers@math.gatech.edu X-Mailing-List: archive/latest/1704 X-Loop: zsh-workers@math.gatech.edu Precedence: list Resent-Sender: zsh-workers-request@math.gatech.edu > It's possible you'd get a little performance, but I don't think it's > worth the effort. Signal blocking/unblocking shouldn't be a very time- > consuming operation, except maybe for the old-style SYSV_SIGNALS or no- > signal-blocking cases. I remember that when signals were blocked instead of queued in mem.c and a blocking/unblocking happened with each zalloc() zsh become more that 2 times slower. Of course zalloc() is called very often and in our case a similar change may not have any noticable effect on the speed. > I'd be willing to bet that the vast majority of those block/unblock pairs > are happening in waitjob() and relatives, where zsh is in a loop doing That's not the case when a cript use mostly builtins. > It's important to block SIGCHLD signals not just before forking, but at > any time you're going to manipulate the job table if any child is still > executing. You could add code to examine the job table and avoid making > the system call when no children exist, but my guess is that would be > just as expensive as simply making the call. I was thinking about queueing the child signals somehow. I started to write something like that but in the end I gave up. Also I'm not fully convinced that the present code rules out all cases when the job table may be changed unexpectedly by an unblocked child signal. > The child blocking stuff corrected a whole bunch of zsh bugs, including > (if I recall correctly) one where pipelines like "/bin/echo foo | less", > where the first command exits very quickly, confused zsh into thinking > the entire pipeline had exited, thus leaving "less" an orphan. Yes, around a fork() blocking seems to be necessary. Zoltan