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
