From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 29176 invoked by alias); 2 Jan 2014 22:46:23 -0000 Mailing-List: contact zsh-workers-help@zsh.org; run by ezmlm Precedence: bulk X-No-Archive: yes List-Id: Zsh Workers List List-Post: List-Help: X-Seq: 32223 Received: (qmail 2272 invoked from network); 2 Jan 2014 22:46:17 -0000 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on f.primenet.com.au X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_LOW autolearn=ham version=3.3.2 X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:date:from:to:subject:message-id:in-reply-to :references:mime-version:content-type:content-transfer-encoding; bh=NKwfQcVe/+bTmRENWlkn34nOAcGO3f/DbneWIV0UrZU=; b=U7jGDQ4KFW+aU/OOr8YkLLf79swaYXwdykQerdxyUkoeZ4+rZmlYLxAu4o00fpzBdA KJH7G4M8hyzMBG+vQZsjo0sU6RFq38aB1CFMPGiIHGkuwnYAQzC3ra6FEIKOr/aG8Q61 uIwtKBU02gjSdNRl+aLVfo7eYkfUI8KPQ9Yl6Fm+8ec7KSnOBmyIKSGgBkWIDkcdmqJ9 KQt3re3pebjsyVQPjYm+oBOSX/EQT1ChLzBHoHC/qD1TcKjBLjlzmDo09kHPs0htMM3O xbcgaNy5OmbFOErUlX6KFwcATdfFAY/nlFr96Pr6mXbrz1OEI4cXX0lfi2OFT0LEGTuj H2cQ== X-Gm-Message-State: ALoCoQm5EmhP7WDuoRN65dOiGewTV3s8tt8Io5pDVoHKaQsqu+eQyxIOwbgoEmlgwVKlwIyCmh95 X-Received: by 10.180.182.164 with SMTP id ef4mr39789108wic.35.1388702442062; Thu, 02 Jan 2014 14:40:42 -0800 (PST) X-ProxyUser-IP: 86.6.157.246 Date: Thu, 2 Jan 2014 22:40:31 +0000 From: Peter Stephenson To: zsh-workers@zsh.org Subject: Re: Possible signal handling issues Message-ID: <20140102224031.1f175f26@pws-pc.ntlworld.com> In-Reply-To: <20140102215505.323946ce@pws-pc.ntlworld.com> References: <131228150234.ZM27671@torch.brasslantern.com> <20140102215505.323946ce@pws-pc.ntlworld.com> X-Mailer: Claws Mail 3.8.0 (GTK+ 2.24.7; x86_64-redhat-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit On Thu, 2 Jan 2014 21:55:05 +0000 Peter Stephenson wrote: > Consequently, this looks to me like some intrinsic race that happens to > be particularly reproducible in the "wait" case. Consider, for example: sleep 20 & TRAPINT() { set -x; kill -INT $$; sleep 1 } wait Now I get the output from the trap as long as I wait for the sleep to finish, but the function doesn't exit. I presume that's because SIGINT is now arriving while the trap is still running (and the fact that ^C within a second has no effect is consistent). Given that traps are intrinsically asynchronous, that's not necessarily related to a bug in the shell. However, it's making the analysis even more complicated. I further note that if I run sleep 20 normally in the foreground (without the sleep in the trap) I get: TRAPINT:0:> kill -INT 25339 TRAPINT:0:> kill -INT 25339 exactly twice. That was consistent with zsh -i with an fg, but not setopt monitor with an fg. I'm guessing (but it's just a guess) that the first time the trap exits quickly so the INT hits just afterwards but the second time there's enough processing around that the signal arrives before the trap has exited (or more precisely before the internal framing of the trap has finished). I'm getting less convinced this is anything more than a you-only-have-yourself-to-blame oddity... pws