Re: process substitution flawed by design

[Florian Mayer]

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?
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?

Like I said, the exact same code works in zsh out of the box without any 
issues.

On 02/20/2017 11:29 PM, Greg Wooledge wrote:
> On Mon, Feb 20, 2017 at 11:25:22PM +0100, Florian Mayer wrote:
> > echo foo | tee >(echo $$) >(echo $$) >/dev/null | cat
> >
> > returns the same PID twice.
> $$ is the PID of the main shell.  I think what you want is the PID of
> each subshell, $BASHPID.
>
> imadev:~$ cat <(echo $$) <(echo $$)
> 3751
> 3751
> imadev:~$ cat <(echo $BASHPID) <(echo $BASHPID)
> 3284
> 3285