Re: Another bug when suspending pipelines

[Peter Stephenson <p.w.stephenson@xxxxxxxxxxxx>]

On Fri, 16 Sep 2016 11:38:01 -0700
Bart Schaefer <schaefer@xxxxxxxxxxxxxxxx> wrote:
> * The parent responds by stopping all the other jobs in the current
>   pipeline.  It forks the brace expression into a new process and
>   stops that one as well (or maybe that one stops itself, I don't
>   recall the exact sequence of events here).

This is where the problem was.  The forked shell is supposed to stop
itself, but because it was in the same process group it was also being
stopped by the parent shell.

> The parent has to manage all three of these jobs, because it can't
> hand off the already-forked "sleep 7" to the newly-forked brace job.
> It has to arrange that the brace job can be sent a SIGCONT on "fg"
> but not actually do anything until the "sleep 7" has finished; I
> believe that's handled by the "synch" pipes and hidden reads; in any
> case, it works.

The parent shell "simply" waits for the non-shell processes that were
forked directly from the parent shell on the right of the pipeline and
restarts the forked shell to run the rest (which may, of course, include
other external processes) when those have finished.  The synch just
ensures syncronisation at the start, though I'm not sure what good it's
doing.

> On "fg" the parent:
> * makes "sleep 7" the tty group leader again
> * sends SIGCONT everywhere

except the forked subshell

> * and waits for "sleep 7" to exit.
?
> If I'm correct about the synch pipe, the tail of the brace expression
> is blocked waiting to read that.

No, it's stopped itself waiting to be resstarted.

> * makes the tail of the brace expression into a process group which
>   becomes the tty leader, and
> * writes a byte on the synch pipe to wake it up.

This all happened in one go when the shell was forked.  (Its process
group is the subject matter here.)

pws