Re: Another bug when suspending pipelines

[Bart Schaefer <schaefer@xxxxxxxxxxxxxxxx>]

On Sep 16,  9:52pm, Peter Stephenson wrote:
} Subject: Re: Another bug when suspending pipelines
}
} On Fri, 16 Sep 2016 11:38:01 -0700
} Bart Schaefer <schaefer@xxxxxxxxxxxxxxxx> wrote:
} > 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.

Hm.  That means that if you *backgound* the "sleep" and bother looking
with "ps", you will see a process that is in T state while the shell
claims it is running.

I suppose that's worked fine for the last lo these many years, but does
it not mean that an external "kill -CONT" can cause the expected order
of events to be violated?

} > * 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.

Maybe it shouldn't.  Ugh.