Re: process substitution flawed by design

[Chet Ramey]

On 2/21/17 8:18 AM, Florian Mayer wrote:
> The following code assumes the lock to be in state not-taken before the
> snippet runs.
> 
> echo foo  | tee \
>     >(mutex --lock; echo before; cat; echo after; mutex --unlock) \
>     >(mutex --lock; echo foobar; mutex --unlock) \
>     > /dev/null | cat
> 
> for mutex --lock I use a tool which I wrote myself. Since I created this
> tool, there is a small chance that an error inside that program is the
> cause for my problem, but that's rather unlikely. The same code works in
> zsh without a problem.
> 
> Now, if the line runs, it sometimes produces the output
> 
> before
> foo
> after
> foobar
> 
> or
> 
> foobar
> before
> foo
> after
> 
> just as one would expect. However, the code occasionally just deadlocks.
> I already found out that deadlocks only occur if I try to read from stdin
> in one of the two >()-blocks.
> 
> How could I try to debug this?

You could attach to the process substitution processes in gdb and see
where they're hanging.

> Has this something to to with how the bash resumes it's work after being
> suspended?
> The only reason I can think of is that somehow cat never exits. Do you
> think that's a reasonable guess?
> And, moreover, cat that even happen?

Sure. If it never reads EOF on stdin.


-- 
``The lyf so short, the craft so long to lerne.'' - Chaucer
                 ``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, UTech, CWRU    chet@case.edu    http://cnswww.cns.cwru.edu/~chet/