[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: process substitution flawed by design
From: |
Greg Wooledge |
Subject: |
Re: process substitution flawed by design |
Date: |
Tue, 21 Feb 2017 08:55:44 -0500 |
User-agent: |
Mutt/1.4.2.3i |
On Tue, Feb 21, 2017 at 02:18:03PM +0100, Florian Mayer wrote:
> for mutex --lock I use a tool which I wrote myself.
What does it do?
> The following code assumes the lock to be in state not-taken before the
> snippet runs.
What lock?
> echo foo | tee \
> >(mutex --lock; echo before; cat; echo after; mutex --unlock) \
> >(mutex --lock; echo foobar; mutex --unlock) \
> > /dev/null | cat
> 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?
I can't imagine how one would debug your mutex program without knowing
anything about it.
> The only reason I can think of is that somehow cat never exits.
Which cat? You've got two. I don't even know what the second one is
for, except to make the problem more complicated. You're not feeding
it any input.