|
From: | Earl Chew |
Subject: | Re: give_terminal_to() / maybe_give_terminal_to() race |
Date: | Sat, 2 Sep 2023 09:40:46 -0700 |
User-agent: | Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:102.0) Gecko/20100101 Thunderbird/102.15.0 |
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
[Prev in Thread] | Current Thread | [Next in Thread] |