[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: process substitution flawed by design

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 4:00 PM, Pierre Gaston <address@hidden> wrote:

On Tue, Feb 21, 2017 at 3:18 PM, Florian Mayer <address@hidden> 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




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.
 ah sorry I read too fast your example, you are expecting that.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]