[Top][All Lists]

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

Re: process substitution flawed by design

From: Chet Ramey
Subject: Re: process substitution flawed by design
Date: Tue, 21 Feb 2017 13:45:45 -0500
User-agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:45.0) Gecko/20100101 Thunderbird/45.7.1

On 2/21/17 8:18 AM, Florian Mayer 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?

You could attach to the process substitution processes in gdb and see
where they're hanging.

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

Sure. If it never reads EOF on stdin.

``The lyf so short, the craft so long to lerne.'' - Chaucer
                 ``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, UTech, CWRU    address@hidden    http://cnswww.cns.cwru.edu/~chet/

reply via email to

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