Boyd Stephen Smith Jr. wrote: > On Friday 05 February 2010 16:33:12 Bob McGowan wrote: >> Boyd Stephen Smith Jr. wrote: >>> mkfifo "LOCM" && >>> mkfifo "FIN" && >>> ( >>> "<" | "NFIND" | "LOCATE" 2> "LOCM" | "FANINANY" 2< "FIN"| ">" & >>> "LOCATE" < "LOCM" > "FIN" & >>> wait >>> ) >> which would disallow having the >> "parallel" processing implied by the above diagram. > > My example runs in parallel. It's virtually required when using fifos. They > aren't normal files -- only so much data can be written to their internal > buffer before further writes block. > > In this case the shell actually starts at least 6 processes. One for each > "utility". Prior to doing the "exec" call in each process, it sets up the > pipes and redirection. It doesn't wait for the processes to finish (notice > the '&' at the end of the pipelines) until I use the wait shell-builtin. > > When the "LOCATE" utility on the second line starts trying to read from stdin > (LOCM) it will block until the "LOCATE" utility on the second line writes > data > to stderr (LOCM) and more-or-less immediately start working on that data as > soon as it arrives. Similarly, "FANINMANY" will block when trying to read > stderr (FIN) just until the "LOCATE" on the second line writes data out to > stdout (FIN).
My point, exactly, though better said ;) If someone wanted to, they could write a single program that would read input/write output from/to two or more descriptors, and use it to create a multi-path'ed I/O processing sequence, but writing it to prevent blocking on one input/output, so it could continue working on the other pair, would be a bit hairy. The fifo node makes this sort of thing easy to do. -- Bob McGowan -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
