Re: Multiple concurrent coprocesses

[Chet Ramey]

On 4/8/21 9:52 PM, Zachary Santer wrote:
> In my code, both coprocesses have a while loop reading from the input
> pipe, so when the writing coproc file descriptor in the main process
> is closed, the while loop and the coproc it's in both end.
>
> Where the coproc-named array variable in the main process is unset as
> soon as the coproc ends, I'm kind of afraid to close its reading file
> descriptor after I close the writing file descriptor. If Bash closes
> the reading file descriptor behind the scenes, as soon as the coproc
> ends, this could present a race condition. Does Bash do this, or would
> the reading file descriptor always still be open, even after the
> coproc has ended and its array variable has disappeared?

It doesn't close the read file descriptor when the coproc ends; what it
does is mark the coproc as dead (coproc_pidchk) when the shell reaps
the coproc child process and then go back later to clean up the
resources (coproc_reap). That's when file descriptors get closed. You
don't want those file descriptors hanging around too long.

> Expanding on what I said earlier, you could even make no attempt to
> keep the coproc file descriptors out of any subshells. If the Bash
> programmer needs to keep them out, he or she has the tools to do so. I
> understand the implication for backwards-compatibility, though.

I think it's safer to manage the coprocs in child processes the way bash
does it now.

--
``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/