|
From: | Pierre Gaston |
Subject: | Re: process substitution flawed by design |
Date: | Tue, 21 Feb 2017 16:05:36 +0200 |
On Tue, Feb 21, 2017 at 3:18 PM, Florian Mayer <mayerflorian@me.com> 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?
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.It's not clear to me why one process should run before the other.The calls to "mutex --lock" can run in parallel the kernel choose one.
[Prev in Thread] | Current Thread | [Next in Thread] |