From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 4950 invoked from network); 16 Dec 2006 21:38:23 -0000 X-Spam-Checker-Version: SpamAssassin 3.1.7 (2006-10-05) on f.primenet.com.au X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00, FORGED_RCVD_HELO autolearn=ham version=3.1.7 Received: from news.dotsrc.org (HELO a.mx.sunsite.dk) (130.225.247.88) by ns1.primenet.com.au with SMTP; 16 Dec 2006 21:38:23 -0000 Received-SPF: none (ns1.primenet.com.au: domain at sunsite.dk does not designate permitted sender hosts) Received: (qmail 78391 invoked from network); 16 Dec 2006 21:38:16 -0000 Received: from sunsite.dk (130.225.247.90) by a.mx.sunsite.dk with SMTP; 16 Dec 2006 21:38:16 -0000 Received: (qmail 28825 invoked by alias); 16 Dec 2006 21:38:13 -0000 Mailing-List: contact zsh-workers-help@sunsite.dk; run by ezmlm Precedence: bulk X-No-Archive: yes X-Seq: 23056 Received: (qmail 28815 invoked from network); 16 Dec 2006 21:38:12 -0000 Received: from news.dotsrc.org (HELO a.mx.sunsite.dk) (130.225.247.88) by sunsite.dk with SMTP; 16 Dec 2006 21:38:12 -0000 Received: (qmail 78051 invoked from network); 16 Dec 2006 21:38:12 -0000 Received: from vms042pub.verizon.net (206.46.252.42) by a.mx.sunsite.dk with SMTP; 16 Dec 2006 21:38:08 -0000 Received: from torch.brasslantern.com ([71.116.86.88]) by vms042.mailsrvcs.net (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPA id <0JAD00HDUYQYPUJD@vms042.mailsrvcs.net> for zsh-workers@sunsite.dk; Sat, 16 Dec 2006 15:37:48 -0600 (CST) Received: from torch.brasslantern.com (localhost.localdomain [127.0.0.1]) by torch.brasslantern.com (8.13.1/8.13.1) with ESMTP id kBGLbkO9024773 for ; Sat, 16 Dec 2006 13:37:46 -0800 Received: (from schaefer@localhost) by torch.brasslantern.com (8.13.1/8.13.1/Submit) id kBGLbj44024772 for zsh-workers@sunsite.dk; Sat, 16 Dec 2006 13:37:45 -0800 Date: Sat, 16 Dec 2006 13:37:45 -0800 From: Bart Schaefer Subject: Re: Is wait not interruptable? In-reply-to: <20061215120557.dc06f65b.pws@csr.com> In-reply-to: <200612152100.kBFL0OTC003197@pwslaptop.csr.com> To: Zsh hackers list Message-id: <061216133745.ZM24771@torch.brasslantern.com> MIME-version: 1.0 X-Mailer: OpenZMail Classic (0.9.2 24April2005) Content-type: text/plain; charset=us-ascii References: <20061215120557.dc06f65b.pws@csr.com> <200612152100.kBFL0OTC003197@pwslaptop.csr.com> Comments: In reply to Peter Stephenson "Re: Is wait not interruptable?" (Dec 15, 12:05pm) Comments: In reply to Peter Stephenson "Re: Is wait not interruptable?" (Dec 15, 9:00pm) On Dec 15, 12:05pm, Peter Stephenson wrote: } } > The ^C was typed 1 second after the command was } > started, and the first sleep plodded along to completion for its full } > 3 seconds. } } I *think* the patch below fixes (b) by sending SIGHUP to our own process } group when exiting from a non-interactive shell, but I'll take advice on } this. (I can at least then get the test program to work with "setopt hup } trapsasync".) The manual isn't clear over whether this is supposed to } happen non-interactively, though it would probably be fair to assume This is a conflict between subshells and other non-interactive shells. I believe a subshell whose parent is an interactive shell should propagate HUP signals to any tasks that it backgrounded, but shells that are non- interactive from the get-go should not. This has to do with the defnition of SIGHUP, which is that it's a signal sent by a controlling TTY to the foreground process group leader when the TTY is disconnected. Shells that are not a foreground group leader are not responsible for propagating HUP signals. This is of course all a mishmash from the way shells work. If a shell has started a foreground job and given that control of the TTY, then when the line drops the foreground job will get HUP'd but the shell will not -- it'll just get EOF after it reaps the foreground job and goes back to read from the terminal again. Generating a HUP to all its other jobs in that circumstance is just to mimic the behavior of the OS signalling the whole process group, which would have happened if the shell had been the foreground job at the time of the hangup. } if HUP is set in a non-interactive shell you'd expect the SIGHUP to be } sent. Well, yes and no. In a non-interactive shell there is theoretically no controlling TTY, so there's no reason to expect to receive a HUP in the first place, so no reason to expect it to be sent either. [In another message] } TRAPSASYNC was really introduced, as the name suggests, to affect trap } execution (see second paragraph of the section in the URL), not the } point at which the signal is delivered to the shell, but in practice it } does the former by altering the latter. The may be a case for always } handling the signal immediately and altering the code only to delay any } traps. But I'm still not sure why it's done the way it is. The signals are handled the way they are mainly because of non-re-entrant libraries (particularly malloc) that can be confused or broken by having signal code executed at an arbitrary point. The "wait" builtin should probably set TRAPS_ASYNC implicitly during its execution, based on the text in 2.11 at that POSIX URL you indicated.