On 4/1/24 3:24 PM, Chet Ramey wrote:
> On 3/14/24 5:58 AM, Carl Edquist wrote:
> 
> 
>> But you can create a deadlock without doing anything fancy.
>>
>>
>> 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.

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