Bash: < & > order is relevant; but why unrelated i/o misordering hangs my pipes?

romagnolo · 02-13-2012, 08:28 AM

Hello,
I've built a FIFOed interface toward gimp-console in the form of a couple of public I/O FIFOs connected to an interpreting bash script which translates incoming commands into dispatches understandable by gimp, and sends them to it using another couple of I/O private FIFOs.

Code:

I/O publicly       +-------------------------+  I/O private FIFOs  +-------+
accessible FIFOs   |         INTERFACE       |  toward Gimp        |       |
------------------>|                         |-------------------->| GIMP  |
<------------------| translator / dispatcher |<--------------------|       |
                   +-------------------------+                     +-------+

Since design, the interface's end side of the two private FIFOs toward gimp have to always be kept open, in the sense that a generic sub-process has to always be fictitiously connected with the two pipes, to prevent hangs of read and write operations performed by gimp (explanation of this behavior is under man 7 pipe).

I succeeded in doing this only in the form of:

Code:

dummy_lasting_process >input_to_gimp <output_from_gimp &
gimp-console --parameters <input_to_gimp >output_from_gimp &

I discovered that if the order of redirection operators in the dummy process is inverted, as in

Code:

dummy_lasting_process <output_from_gimp >input_to_gimp &
gimp-console --parameters <input_to_gimp >output_from_gimp &

both the dummy process and gimp hang up, suggesting that the ending of one or both of the pipes is open.
I see no reason for this.

romagnolo · 02-13-2012, 12:12 PM

More generally, I found these hangs happening with whatever other couple of processes. For example:

Code:

# preliminar
mkdir testdir
cd testdir
mkfifo A B

this completes execution:

Code:

# example 1
/bin/sleep 100 >A <B &
ls <A >B

this hangs up, probably waiting for pipes clearance:

Code:

# example 2
/bin/sleep 100 <B >A &
ls <A >B

jonjgc · 02-13-2012, 06:07 PM

Two things come into play here, first, the shell processes
redirection from left to right.

Second, the shell would be opening these FIFO's in
"blocking mode". If nothing is attached to the other end,
the open will not complete until the other end is opened.

In your first case, sleep starts to open A and blocks.
It is in the background so ls also runs completing the
opening of the other end of A.

In the second case sleep blocks on opening B and hasn't
yet tried to open A. Then ls opens A and blocks because
the other end of A is not, and never will be opened by
sleep which is blocked trying to open B which ls has
not opened and can't because it is blocked.

Reversing the redirections on ls in the second case
should also work.

I've never tried it, but opening both ends but only
using one might work too.

sleep 100 <> B > A &
ls < A > B

By opening B for both reading and writing it might
not block and thus would open A. I don't know if
it would be important to close the read end of B
to make sure only one process had it open, but if
so this might also work, again untried.

sleep 100 <> B >&- > A &

romagnolo · 02-14-2012, 09:29 AM

Thank you for the precious insight. I will study your examples as time permits.