From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 8718 invoked from network); 22 Apr 2004 10:00:32 -0000 Received: from sunsite.dk (130.225.247.90) by ns1.primenet.com.au with SMTP; 22 Apr 2004 10:00:32 -0000 Received: (qmail 22572 invoked by alias); 22 Apr 2004 10:00:27 -0000 Mailing-List: contact zsh-workers-help@sunsite.dk; run by ezmlm Precedence: bulk X-No-Archive: yes X-Seq: 19814 Received: (qmail 22538 invoked from network); 22 Apr 2004 10:00:26 -0000 Received: from localhost (HELO sunsite.dk) (127.0.0.1) by localhost with SMTP; 22 Apr 2004 10:00:26 -0000 X-MessageWall-Score: 0 (sunsite.dk) Received: from [130.225.247.86] by sunsite.dk (MessageWall 1.0.8) with SMTP; 22 Apr 2004 10:0:26 -0000 Received: (qmail 5743 invoked from network); 22 Apr 2004 10:00:26 -0000 Received: from lhuumrelay3.lnd.ops.eu.uu.net (62.189.58.19) by a.mx.sunsite.dk with SMTP; 22 Apr 2004 10:00:25 -0000 Received: from MAILSWEEPER01.csr.com (mailhost1.csr.com [62.189.183.235]) by lhuumrelay3.lnd.ops.eu.uu.net (8.11.0/8.11.0) with ESMTP id i3M9xvv11224 for ; Thu, 22 Apr 2004 09:59:58 GMT Received: from EXCHANGE02.csr.com (unverified [192.168.137.45]) by MAILSWEEPER01.csr.com (Content Technologies SMTPRS 4.3.12) with ESMTP id ; Thu, 22 Apr 2004 10:59:30 +0100 Received: from csr.com ([192.168.144.127]) by EXCHANGE02.csr.com with Microsoft SMTPSVC(5.0.2195.6713); Thu, 22 Apr 2004 11:00:42 +0100 To: Vincent Stemen cc: Zsh hackers list Subject: Re: PATCH: (2) Re: FreeBSD compatability feature request In-reply-to: "Vincent Stemen"'s message of "Thu, 22 Apr 2004 03:59:56 CDT." <20040422085956.GA69814@quark.hightek.org> Date: Thu, 22 Apr 2004 10:59:57 +0100 Message-ID: <17122.1082627997@csr.com> From: Peter Stephenson X-OriginalArrivalTime: 22 Apr 2004 10:00:42.0189 (UTC) FILETIME=[AC0797D0:01C42850] X-Spam-Checker-Version: SpamAssassin 2.63 on a.mx.sunsite.dk X-Spam-Level: X-Spam-Status: No, hits=0.2 required=6.0 tests=EXCUSE_16 autolearn=no version=2.63 X-Spam-Hits: 0.2 Vincent Stemen wrote: > However, I actually tested the signal handling this time and, unless I > am not understanding the trapsasync mode enough to test properly, I > don't think it is working. If I understand it correctly, with "set -T" > shouldn't the parent process immediately get any signals it has trapped > even if a child process it is waiting on has disabled the signals? I think you're right. I didn't do anything with basic signal handling (which I don't know much about), just rewrote the way traps are queued. It looks like it will need someone to rewire the signal handling not to block other signals in this case. The function is signal_suspend() in signals.c which calls sigfillset() then removes SIGCHLD from the blocked set. However, that now gives us three different modes: the original zsh one, POSIX where all traps are deferred, and this mode where signals are delivered straight through. So one option isn't enough. Presumably TRAPS_ASYNC should be off for the standard zsh behaviour, on for the new behaviour, and we need another option for POSIX which will be overridden if TRAPS_ASYNC is set. Yuk. -- Peter Stephenson Software Engineer CSR Ltd., Science Park, Milton Road, Cambridge, CB4 0WH, UK Tel: +44 (0)1223 692070 ********************************************************************** This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system manager. This footnote also confirms that this email message has been swept by MIMEsweeper for the presence of computer viruses. www.mimesweeper.com **********************************************************************