From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 10695 invoked from network); 31 Jan 2000 10:01:22 -0000 Received: from sunsite.auc.dk (130.225.51.30) by ns1.primenet.com.au with SMTP; 31 Jan 2000 10:01:22 -0000 Received: (qmail 8244 invoked by alias); 31 Jan 2000 10:01:03 -0000 Mailing-List: contact zsh-workers-help@sunsite.auc.dk; run by ezmlm Precedence: bulk X-No-Archive: yes X-Seq: 9488 Received: (qmail 8234 invoked from network); 31 Jan 2000 10:01:03 -0000 Date: Mon, 31 Jan 2000 11:00:40 +0100 (MET) Message-Id: <200001311000.LAA29263@beta.informatik.hu-berlin.de> From: Sven Wischnowsky To: zsh-workers@sunsite.auc.dk In-reply-to: "Bart Schaefer"'s message of Sat, 29 Jan 2000 18:13:29 +0000 Subject: Re: PATCH: job-control Bart Schaefer wrote: > (Yes, I'm still behind.) > > On Jan 18, 12:36pm, Sven Wischnowsky wrote: > } Subject: PATCH: job-control > } > } Here is the fix for the problem mentioned in 9332. > } > } The second problem turned out to be two problems. If one hit ^Z early > } enough to suspend the cat, the then-sub-shelled loop wasn't continued > } and the less wasn't executed. [...] This was because at the time of > } the inner waitjobs() child_block() was active so it found out that the > } pipe-leader was suspended too late. This is fixed by the hunk that > } adds a child_block/unblock() before the waitjobs(). This is the hunk > } I'm least happy about. Bart, can you think of any problems with this? > > The only "problem" is that I can't figure out why it makes any difference. > > If it really is somehow the case the "it found out that the pipe-leader > was suspended too late," then it seems to me that the while() condition > in waitjob() is what needs fixing, or we still have a race condition: > the ^Z could suspend the pipe-leader between the child_block() and the > while() test within waitjob(). All that this change has done is shrink > the window. No, the important bit is the child_unblock() which makes the signal handler be run for all pending signals (we are blocking child signals during most of the execution code), so that the job and process infos are updated. Without the patch this happened only when a execpline() finished (shortly before that). In the test case there were two of them active and we need to know that the leader was suspended in the inner one but since child-signals were only delivered after the call to waitjobs(), we could see that only in the outer execpline(). > Also, the child_block() call following the unblock in exec.c is redundant, > because block/unblock are not stacked and the first thing that waitjobs() > does [via waitjob()] is to call child_block(). Yes, I saw that at the weekend, too (I'm playing with a non-recursive execution code at home). Bye Sven diff -ru ../z.old/Src/exec.c Src/exec.c --- ../z.old/Src/exec.c Mon Jan 31 10:49:45 2000 +++ Src/exec.c Mon Jan 31 10:56:15 2000 @@ -982,7 +982,6 @@ } if (!(jn->stat & STAT_LOCKED)) { child_unblock(); - child_block(); waitjobs(); } if (list_pipe_child && -- Sven Wischnowsky wischnow@informatik.hu-berlin.de