Bash: < & > order is relevant; but why unrelated i/o misordering hangs my pipes?
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 +-------+ I succeeded in doing this only in the form of: Code:
dummy_lasting_process >input_to_gimp <output_from_gimp & Code:
dummy_lasting_process <output_from_gimp >input_to_gimp & I see no reason for this. |
More generally, I found these hangs happening with whatever other couple of processes. For example:
Code:
# preliminar Code:
# example 1 Code:
# example 2 |
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 & |
Thank you for the precious insight. I will study your examples as time permits.
|
All times are GMT -5. The time now is 08:05 AM. |