1Pipelining streams or Point, Counter Point0

[Mark Bromley <bromley@think.com>]

   Date: Wed, 28 Oct 87 18:18 EST
   From: Robert W. Kerns <RWK@yukon.scrc.symbolics.com>
   Character-Type-Mappings: (1 0 (NIL 0) (:SWISS NIL NIL) "HL12")
   Fonts: CPTFONT, HL12
   Resent-Date: Wed 28 Oct 87 18:24:06-CST
   Resent-From: CMP.SLUG@r20.utexas.edu
   Resent-To: SLUG:;@r20.utexas.edu

   0Coroutine streams are not, strictly speaking, concurrent.
   However, they *do* provide for interleaved execution.
   The source side runs just long enough to fill up the
   buffer, then the input side runs just long enough to
   empty it again, and back to the output side.

   If the only way the two programs have of communicating is
   by the coroutine stream, they can't tell the difference.

   Coroutine streams are useful much much more often in
   our system than pipes.  In fact, one barrier to documenting
   pipes is that it is rather difficult to construct a non-silly
   example where pipes are to be preferred over coroutine streams.

   In particular, nearly every Unixoid use of pipes is better
   done with coroutine streams.


I don't understand this at all.  A "Unixoid" pipe is exactly a coroutine
stream.  In standard Unix, a pipe is a communication channel between a
producer process and a consumer process.  There is no true concurrency,
rather processes execute in a coroutine fashion.  Any attempt by the
producer to write to the communication channel when its buffer is full
causes the producer process to sleep, allowing other processes a chance at
the cpu.  Any attempt by the consumer process to read when the buffer is
empty will cause it to sleep, allowing other processes to execute.  Other
than the fact that the policy for when the producer and consumer processes
execute is more flexible, there is no difference between this and what you
have outlined above.

Small wonder you couldn't find any examples where whatever you think a pipe
is would be preferred to a coroutine stream.

Mark Bromley
bromley@think.com