Re: Controlling terminal race condition

[Chet Ramey]

Paul Jarc wrote:
> Jeff Miller <miller@argus-systems.com> wrote:
> 
>>It is possible on our test Solaris 8 system that the original
>>calling bash shell will set the controlling process of the terminal
>>to the pid that it originally forked to after the new process had
>>been created. In this case is not the new bash process. It happens
>>to do this after the new bash has done it's write but before it has
>>done it's read, this new process still assumes it is still the
>>controlling process.
> 
> 
> Chet, could the foreground process group be set by the forked child
> itself, before the exec, instead of by the parent?  That would at
> least eliminate the race condition so the results would be
> predictable, and I think it would prevent the problem in this case.

It is.  The terminal process group is set N+1 times in a N-stage
pipeline:  once by each child, and once by the parent.  This was
considered `best practice' by the POSIX people when I put it in.
I still think it's the best way to avoid problems.

Chet
-- 
``The lyf so short, the craft so long to lerne.'' - Chaucer
( ``Discere est Dolere'' -- chet )
                                                Live...Laugh...Love
Chet Ramey, ITS, CWRU    chet@case.edu    http://cnswww.cns.cwru.edu/~chet/