On 2023-08-30 07:39, Chet Ramey wrote:
OK, so there is a potential race condition here. What do you suggest the right approach might be? It seems to me we can do one of two things: rearrange and extend the PGRP_PIPE code to make sure the child process doesn't proceed until the parent sets the terminal process group; or change stop_pipeline() (and audit its callers, of course) so it does not set the terminal process group.
I experimented a bit, and gave the matter some thought. The controlling terminal must be reconfigured before the parent gets to wait() for the job, and before the child gets to exec() the program (or their equivalents). This means that there must be some synchronisation to ensure that these conditions are true. Either the parent must yield the controlling terminal, or the child must acquire the controlling terminal, and the other must block until the outcome has been achieved. Since PGRP_PIPE supports the parent providing a synchronisation signal, it aligns with the parent yielding the controlling terminal. Presently, there is no mechanism for the child to trigger a synchronisation with the parent. For this reason, I think the first option you list is a more straightforward fit for the implementation. Should I go ahead and propose a patch? Earl
