I'm working on a project where one process will be working with a stream of data from a series of separate processes. We currently have an architecture where process A (the controller) starts up process B (the source). The output from B is directed into a named pipe (created earlier with mkfifo). Meanwhile, process C (the sink) is reading from the named pipe. After B exits, A will start up a new one, and so one. [Side note: We have little control of process B. It is a program from another source that simply outputs to stdout. We redirect its stdout to the named pipe.] This system works, but has occasional glitches where the output stream from C is momentarily interrupted. They appear to be due to the 4K capacity of the pipe, combined with the fact that new data from B is not appearing in the pipe until after the pipe is completely empty. As C reads, the size of the pipe decreases until it reaches 0, at which point it suddenly jumps back to 4096. Occasionally, C will read the pipe again after it has been emptied, but before B has finished filled it again. When that happens, there is a momentary break in C's output, which is undesirable. One thought I've had to try to resolve the problem is to use a regular pipe instead of a named pipe. Process A would create a pipe, then fork off C which would keep its end of the pipe open for the duration of its run (days, weeks, months... this ain't NT! :) Then A would fork off the series of B processes, one at a time, with their stdout mapped to the input of the pipe. What I'm wondering is if there might be any problem with having a whole series of processes outputting to the same pipe, which is held open by a long-lived process at the other end of the pipe. Or would this arrangement be likely to have the same problem as the current one? For that matter, does anyone have better suggestions how to proceed? Thanks for your insight, and please CC: me on replies. Dave ---------------------------------------------------------------------- Dave Walton [EMAIL PROTECTED] ---------------------------------------------------------------------- To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
