From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 10672 invoked by alias); 24 Dec 2011 10:08:28 -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: 30055 Received: (qmail 7906 invoked from network); 24 Dec 2011 10:08:16 -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=-1.9 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_NONE, SPF_HELO_PASS autolearn=ham version=3.3.2 Received-SPF: none (ns1.primenet.com.au: domain at bewatermyfriend.org does not designate permitted sender hosts) From: Frank Terbeck To: zsh-workers@zsh.org Subject: Re: $pipestatus broken? In-Reply-To: <111224013252.ZM22819@torch.brasslantern.com> (Bart Schaefer's message of "Sat, 24 Dec 2011 01:32:52 -0800") References: <87borgzkap.fsf@ft.bewatermyfriend.org> <877h24zj69.fsf@ft.bewatermyfriend.org> <111210065833.ZM6198@torch.brasslantern.com> <877h1nwojx.fsf@ft.bewatermyfriend.org> <111223133128.ZM17298@torch.brasslantern.com> <87hb0rueem.fsf@ft.bewatermyfriend.org> <111224013252.ZM22819@torch.brasslantern.com> User-Agent: Gnus/5.110018 (No Gnus v0.18) Emacs/24.0.91 (gnu/linux) Date: Sat, 24 Dec 2011 10:59:49 +0100 Message-ID: <878vm2uw6i.fsf@ft.bewatermyfriend.org> MIME-Version: 1.0 Content-Type: text/plain X-Df-Sender: NDMwNDQ0 Bart Schaefer wrote: > On Dec 23, 11:11pm, Frank Terbeck wrote: > } ...unless, of course, the loop just needs to be there to delay the RHS, > } for the exit/reap to happen as you suggested. > > Hmm, this is getting a bit hairy. > > In the simple case { echo foo | read -E }, there is a single job table > entry for "read" which is the group leader for the pipeline. > > In the loop case { echo foo | repeat 1; read -E } there is a job table > entry for the loop which is the group leader, but a new entry is > created for "read -E". execpline() remembers the previous thisjob as > the local "pj" and restores thisjob = pj at line 1619, but by that > time it is too late -- waitjobs() has set thisjob = -1 for just long > enough for zhandler() to call update_job(), which fails to update the > pipestats because thisjob = -1 tells it there is no current job. > > The following seems to fix it, by telling waitjobs() what the previous > job number was so it can be reset immediately. There may still be a > race condition that requires fiddling with signal blocks to make sure > thisjob is correct at the time the zhandler() catches the signal, but > if so this should at least allow the block/unblock to be localized. Hm. I'm having a hard time following what's going on... With this change, the test I posted in workers-30047 changes a bit. Before, there were only lines that either looked like "1" or "0 0". Now I'm getting "0 1", too. "1" and "0 1" seem to happen way less now - both cases are in the 1% area each. But maybe I'm just a little luckier, with respect to timing. Regards, Frank