[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
1Pipelining streams or Point, Counter Point0
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
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.