On Tue, Feb 21, 2017 at 4:00 PM, Pierre Gaston <pierre.gas...@gmail.com> wrote:
> > > 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. > ah sorry I read too fast your example, you are expecting that.
