Re: PATCH: job-control

["Bart Schaefer" <schaefer@candle.brasslantern.com>]

(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.

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().

-- 
Bart Schaefer                                 Brass Lantern Enterprises
http://www.well.com/user/barts              http://www.brasslantern.com