On 2023-09-01 09:07, Chet Ramey wrote:
On 9/1/23 11:48 AM, Earl Chew wrote:
What remains might be whether there is value in maintaining the
present barrier in both parent and child so that it is
straightforward to reason about designation of the
foreground process in the controlling terminal.
What makes the current implementation, where each child and the parent all
change the terminal pgrp, more "straightforward" than leaving the change to
each child, if the change serves to eliminate the potential race condition?
I'm thinking that having a point, in both parent and child, after which
there is a guarantee that the foreground group is no longer changed
makes it more straightforward to reason about consequences.
I agree that for correctness, it is sufficient that responsibility
for making the change be left to the children.
AFAICT it is the first child that establishes the pgid of the new
process group. For correctness the terminal process group must
be configured before any of the children exec() their target programs.
Given that the children must synchronise before exec(), there is no
issue if all configure the terminal though it is sufficient
if only the first child does so.
Looking at the code, it seems that the PGRP_PIPE feature is sufficient
to achieve the synchronisation, though at present this code is not
compiled for all platforms.
Earl
