Path: utzoo!utgpu!news-server.csri.toronto.edu!rutgers!apple!olivea!orc!inews!iwarp.intel.com!gargoyle!chinet!les
From: les@chinet.chi.il.us (Leslie Mikesell)
Newsgroups: comp.unix.questions
Subject: Re: Piping into two processes simultaneously
Message-ID: <1990Sep12.191501.17843@chinet.chi.il.us>
Date: 12 Sep 90 19:15:01 GMT
References: <17680:Sep1021:08:2890@kramden.acf.nyu.edu> <1990Sep11.034811.14492@chinet.chi.il.us> <20005:Sep1114:10:2290@kramden.acf.nyu.edu>
Distribution: usa
Organization: Chinet - Chicago Public Access UNIX
Lines: 31

In article <20005:Sep1114:10:2290@kramden.acf.nyu.edu> brnstnd@kramden.acf.nyu.edu (Dan Bernstein) writes:

>It's axiomatic that you lose turnaround time when your slowest process
>is forced to block. (The weakest link...) Say you have data flowing from
>A into B into C into F, and from A into D into E into F. Say B and E are
>the bottlenecks. Now if we use your tee-based solution for the A-B-D
>split, then D will block as soon as B does. E won't get all its data
>until B is basically done. So you've pretty much doubled your turnaround
>time.

>Now do you understand the problem?

I understand the situation, but I don't see why it should be a problem
unless the producer is interactive with the faster of the two consumers.
Otherwise you're not done till you're all done, and you might as well
pace the output to the slowest consumer.

>multitee notices when an output blocks and sends the data to the other
>outputs. It can in theory be configured to buffer up to the memory size,
>but with any buffer it has a much lower chance than tee of being the
>bottleneck in a pipeline.

But pipes buffer all by themselves, up to PIPE_BUF anyway so the
processes don't have to sync down to the read/write level.  I don't
see the gain from any additional buffering except in the odd situation
noted above.  Most programs are going to use block buffered stdio going
into the pipe in the first place which is good for efficiency but not
for interactive type things.

Les Mikesell
  les@chinet.chi.il.us