Re: process substitution flawed by design

[Florian Mayer]

> What does it do?
It behaves like the p-operation on unary Sys-V semaphores. If the semaphore has 
not been taken (has had the value 1), mutex --lock immediately exits. If the 
semaphore has indeed been taken already (has the value 0), mutex --lock will 
try to gain the lock and only exit if it was successfull.
> What lock?
lock = mutex in this context

> I can't imagine how one would debug your mutex program without knowing
> anything about it.
Like I said, my program is probably not the root of the problem, because 
everything works fine in another shell...
(Here is the source https://github.com/forflo/basem)

> 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.
The last cat in the pipe behaves like a join. It collects the output of 
all subshells and returns it as one continuous stream
to the stdout of the current shell. The first cat inside one of the 
process substitution blocks presumably leads to the problem due to a 
sync issue. But, as I said, I don't know why or if that's really the cause.

If you really want to dig into the problem. The precise shell line would be

$ basem --create --rights 0600 --key 123 # creates a SYS-V semaphore 
usable with key 123
$ echo foo | tee \
    >(basem --key 123 --pop; echo before; cat; echo after; basem --key 
123 --vop) \
    >(basem --key 123 --pop; echo foobar; basem --key 123 --vop) \
    > /dev/null | cat

which uses basem. Call basem --h for concrete syntax.

On 02/21/2017 02:55 PM, Greg Wooledge wrote:
> 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.