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