From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 16675 invoked by alias); 2 Jan 2014 21:55:16 -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: 32222 Received: (qmail 25429 invoked from network); 2 Jan 2014 21:55:10 -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=TJEnsatuoGWFbRp9iP/dodFCWVlqjiVyM4ZlhtUWJgw=; b=jtTawG0vITSEESGFnP6XDLMrk+G+gflI190/nO3AbZ6uIf+dbYoUPvaOgcbSq4nBCJ 84hGvX7Z1YXD4AzmnsreIKKmJqlIFWYw+MA4difPze/UvAbLQIYGwfBaNqV1oqwxW3vq sp8hUl8crrmQDNv+2QsgpZdxD7AEht4rf5/ywKq5qy71dlOSCcg8CMnbPGhGhvy48YVB Mrqw1ZMRfk4mT5B6z9FmmcOIyRASOVfytP5Fyp3+W1j0dUTSv1Ywh17H1pbdad3P1me6 i3Db4huIi+0E0uDQZWS/UPnnMKScsYLJohrw/flfUEC5/qpPbGwIQnp+phP3kc80KBd0 CL2Q== X-Gm-Message-State: ALoCoQmcOCO0hbaQj0pgTN0Q5Kv0vCZ2HlhQEPj8rUg2WRE8BNbaqbUUr88dQji+IgbzJDtN6HBD X-Received: by 10.180.106.165 with SMTP id gv5mr29183583wib.32.1388699708240; Thu, 02 Jan 2014 13:55:08 -0800 (PST) X-ProxyUser-IP: 86.6.157.246 Date: Thu, 2 Jan 2014 21:55:05 +0000 From: Peter Stephenson To: zsh-workers@zsh.org Subject: Re: Possible signal handling issues Message-ID: <20140102215505.323946ce@pws-pc.ntlworld.com> In-Reply-To: <131228150234.ZM27671@torch.brasslantern.com> References: <131228150234.ZM27671@torch.brasslantern.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 Sat, 28 Dec 2013 15:02:34 -0800 Bart Schaefer wrote: > Both of these have been around since at least 4.2.0. Consider this script: > > --- snip --- > sleep 20 & > TRAPINT() { set -x; kill -INT $$ } > wait > --- snip --- > > Run that in the foreground, kill it with ctrl+c, and watch the infinite > loop. Something to do with the "wait" command allows the INT to be re- > queued for handling even when it is sent from inside an INT trap. The > signal_suspend() in zwaitjob() is constantly re-interrupted and never > returns. The following doesn't get us much further, but I'm not sure executing "wait" is the key thing here: I think it might be more to do with the fact that the job was first started in the background. The following is less than conclusive, however, since "fg" shares a lot of code with "wait". I first tried modifying the above to set -x # for earlier (de?)mystification sleep 20 & TRAPINT() { set -x; kill -INT $$ } fg and then running with "zsh -fi" (something in my startup files is causing a hang without the -f, which is irrelevant, but that's why I went on and tried the other version below before I found that out). I got ../zwaitjob2.sh:3:> sleep 20 ../zwaitjob2.sh:5:> fg %sleep [1] + 1792 running sleep 20 ^C reproducibly gives +TRAPINT:0> set -x +TRAPINT:0> kill -INT 2004 +TRAPINT:0> set -x +TRAPINT:0> kill -INT 2004 Then I tried: set -x print $$ setopt monitor sleep 20 & TRAPINT() { set -x; kill -INT $$ } fg %sleep Initially I got +../zwaitjob3.sh:2> print 1907 1907 +../zwaitjob3.sh:3> setopt monitor [1] 1910 +../zwaitjob3.sh:4> sleep 20 +../zwaitjob3.sh:6> fg %sleep [1] + running sleep 20 This time ^C or "kill -INT 1907" doesn't do anything. I'm not sure what's going on here. However, if I send "kill -INT 1910" (killing the forked process) from outside I see some variable number of repetitions of +TRAPINT:0> kill -INT 1922 +TRAPINT:0> set -x and then the shell exits. Consequently, this looks to me like some intrinsic race that happens to be particularly reproducible in the "wait" case. However, this still seems to be different to the second problem. I wondered whether the race was due to the places where signals were being queued and unqueued, but haven't got anywhere down that route, and I don't know why this is different when the process wasn't backgrounded. I have a vague memory we do something about blocking ^C when starting a job in the background, though? pws