Re: Examples of concurrent coproc usage?

[Chet Ramey]

On 3/14/24 5:58 AM, Carl Edquist wrote:

> HOWEVER!!!
>
> Unexpectedly, the new multi-coproc code seems to close the user shell's end 
> of a coprocess's pipes, once the coprocess has terminated.  When compiled 
> with MULTIPLE_COPROCS=1, this is true even if there is only a single coproc:
>
>      $ coproc WC { wc; }
>      $ exec {WC[1]}>&-
>      [1]+  Done                    coproc WC { wc; }
>
>      # WC var gets cleared!!
>      # shell's ${WC[0]} is also closed!
>
>      # now, can't do:
>
>      $ read -u ${WC[0]} X
>      $ echo $X
>
> I'm attaching a "bad-coproc-log.txt" with more detailed ps & ls output 
> examining the open fds at each step, to make it clear what's happening.

It's straightforward: the coproc process terminates, the shell reaps it,
marks it as dead, notifies the user that the process exited, and reaps it
before printing the next prompt. I don't observe any different behavior
between the default and when compiled for multiple coprocs.

It depends on when the process terminates as to whether you get a prompt
back and need to run an additional command before reaping the coproc
(macOS, RHEL), which gives you the opportunity to run the `read' command:

$ coproc WC { wc; }
[1] 48057
$ exec {WC[1]}>&-
$ read -u ${WC[0]} X
[1]+  Done                    coproc WC { wc; }
bash: DEBUG warning: cpl_reap: deleting 48057
$ echo $X
0 0 0

(I put in a trace statement to show exactly when the coproc gets reaped and
deallocated.)

I can't reproduce your results with non-interactive shells, either, with
job control enabled or disabled.


> This is a bug.  The shell should not automatically close its read pipe to a 
> coprocess that has terminated -- it should stay open to read the final 
> output, and the user should be responsible for closing the read end 
> explicitly.

How long should the shell defer deallocating the coproc after the process
terminates? What should it do to make sure that the variables don't hang
around with invalid file descriptors? Or should the user be responsible for
unsetting the array variable too? (That's never been a requirement,
obviously.)


> It also invites trouble if the shell variable that holds the fds gets 
> removed unexpectedly when the coprocess terminates.  (Suddenly the variable 
> expands to an empty string.)  It seems to me that the proper time to clear 
> the coproc variable (if at all) is after the user has explicitly closed 
> both of the fds. 

That requires adding more plumbing than I want to, especially since the
user can always save the file descriptors of interest into another
variable if they want to use them after the coproc terminates.

> *Or* else add an option to the coproc keyword to 
> explicitly close the coproc - which will close both fds and clear the 
> variable.

Not going to add any more options to reserved words; that does more
violence to the grammar than I want.

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