Zsh Mailing List Archive
Messages sorted by:
Reverse Date,
Date,
Thread,
Author
Re: PATCH: job-control
- X-seq: zsh-workers 9488
- From: Sven Wischnowsky <wischnow@xxxxxxxxxxxxxxxxxxxxxxx>
- To: zsh-workers@xxxxxxxxxxxxxx
- Subject: Re: PATCH: job-control
- Date: Mon, 31 Jan 2000 11:00:40 +0100 (MET)
- In-reply-to: "Bart Schaefer"'s message of Sat, 29 Jan 2000 18:13:29 +0000
- Mailing-list: contact zsh-workers-help@xxxxxxxxxxxxxx; run by ezmlm
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@xxxxxxxxxxxxxxxxxxxxxxx
Messages sorted by:
Reverse Date,
Date,
Thread,
Author