Re: give_terminal_to() / maybe_give_terminal_to() race

[Chet Ramey]

On 9/2/23 12:40 PM, Earl Chew wrote:
> 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.

Such as? If the parent doesn't need to change the terminal process group,
synchronizes with the pipeline via waitpid(), and doesn't attempt to change
the terminal process group back until all children in that process group
have stopped or exited, what consequences are of concern?


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

Each child sets the terminal process group before going on, so this is
satisfied.

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

Not true; the scheduler is allowed to run any child first, so in theory
it's possible for another process in the pipeline to try to read from
the terminal before the process group leader sets the terminal pgrp.


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

The synchronization PGRP_PIPE provides exists for another purpose. Some
versions of Linux require that the process group leader be alive if
another process calls setpgid() or tcsetpgrp() specifying that pgrp, so
PGRP_PIPE forces the process group leader to wait until all pipeline
elements are created before going on. There is a configure test for it.

--
``The lyf so short, the craft so long to lerne.'' - Chaucer
                 ``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, UTech, CWRU    chet@case.edu    http://tiswww.cwru.edu/~chet/