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 c...@case.edu http://cnswww.cns.cwru.edu/~chet/
