From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <zsh-workers-request@euclid.skiles.gatech.edu>
Received: (qmail 4344 invoked from network); 11 Jan 1997 19:29:24 -0000
Received: from euclid.skiles.gatech.edu (list@130.207.146.50)
  by coral.primenet.com.au with SMTP; 11 Jan 1997 19:29:24 -0000
Received: (from list@localhost) by euclid.skiles.gatech.edu (8.7.3/8.7.3) id OAA02644; Sat, 11 Jan 1997 14:36:56 -0500 (EST)
Resent-Date: Sat, 11 Jan 1997 14:36:56 -0500 (EST)
Message-Id: <199701111936.OAA11446@cypress.skiles.gatech.edu>
To: zsh-workers@math.gatech.edu
Subject: Re: signal weirdness fix 
In-reply-to: Your message of "Sat, 11 Jan 1997 10:50:41 PST."
             <970111105041.ZM1400@candle.brasslantern.com> 
Date: Sat, 11 Jan 1997 14:36:46 -0500
From: Richard Coleman <coleman@math.gatech.edu>
Resent-Message-ID: <"CooR63.0.Cf.Nl-ro"@euclid>
Resent-From: zsh-workers@math.gatech.edu
X-Mailing-List: <zsh-workers@math.gatech.edu> archive/latest/2778
X-Loop: zsh-workers@math.gatech.edu
Precedence: list
Resent-Sender: zsh-workers-request@math.gatech.edu

> 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.

I agree with Zoltan here.  Zsh executes way too much code in its
signal handlers.  But fixing it is non-trivial.  And it is complicated
by the way we handle `errflag'.  I think it might be easier to change
the way errors are handled first (using setjmp, longjmp), and then
work on the signal handling code.

rc