On Mon, 1 Apr 2024, Chet Ramey wrote:

> On 4/1/24 3:24 PM, Chet Ramey wrote:
>>  On 3/14/24 5:58 AM, Carl Edquist wrote:
>>
>>>  Well, *without multi-coproc support*, here's a simple wc example; first
>>>  with a single coproc:
>>>
>>>       $ coproc WC { wc; }
>>>       $ exec {WC[1]}>&-
>>>       $ read -u ${WC[0]} X
>>>       $ echo $X
>>>       0 0 0
>>>
>>>  This works as expected.
>>>
>>>  But if you try it with a second coproc (again, without multi-coproc
>>>  support), the second coproc will inherit copies of the shell's read and
>>>  write pipe fds to the first coproc, and the read will hang (as described
>>>  above), as the first coproc doesn't see EOF:
>>>
>>>       $ coproc WC { wc; }
>>>       $ coproc CAT { cat; }
>>>       $ exec {WC[1]}>&-
>>>       $ read -u ${WC[0]} X
>>>
>>>       # HANGS
>>> 
>>>
>>>  But, this can be observed even before attempting the read that hangs.
>>
>>  Let's see if we can tackle these one at a time. This seems like it
>>  would be pretty easy to fix if a coproc closed the fds corresponding
>>  to an existing coproc in the child after the fork. That wouldn't
>>  really change anything regarding how scripts have to manually manage
>>  multiple coprocs, but it will prevent the shell from hanging.
>> 
>
> I sent this before I was ready. This would be equivalent to changing the 
> commands to use
>
> coproc CAT { exec {WC[0]}<&- {WC[1]}>&- ; cat; }
>
> but the script writer wouldn't have to manage it.


Agreed.

And just to note two things (in case it wasn't clear) - (1) the above 
example that hangs is with the default bash, compiled _without_ 
multi-coproc support; and (2):

> This seems like it would be pretty easy to fix if a coproc closed the 
> fds corresponding to an existing coproc in the child after the fork

the forked coproc has to close its fds to/from _all_ other existing 
coprocs (as there can be several).


Carl