Very Computer

This is a reasonable idea.  What I think you really need is for pipes
to be implemented as (full-duplex) streams, the way Dennis had them in
Eighth Edition UNIX.  He also had an ioctl for passing stream file
descriptors (over such a pipe) to other processes; it does appear that
SVR3.0 picked up this latter feature (in a different way; boy is their
STREAMS implementation more elaborate than Dennis's!) but so far as I
can determine solely by looking at the documentation, SVR3.0 does not
have much of the character I/O system converted to STREAMS; in
particular pipes seem to still be ripped-off disk inodes.  (Dennis
re-implemented FIFOs as streams on his Cray SVR2 after putting in his
version of streams, and the result was smaller and cleaner than the
original SVR2 FIFOs.)  I have the impression that SVR4.0 will at least
have the terminal handler converted to STREAMS (this seems to imply
that the M_DELIM control packets are being put back in), which is
important since it allows much of the host terminal I/O processing to
be moved out into intelligent controllers, or even into a smart
terminal such as a Blit, in a very clean way.  Whether or not pipes
and FIFOs will ever be assimilated into STREAMS I do not know, but I
sure hope they are.  Then you would have a really slick way to do what
you seem to be after (stream splicing).

Quote:>I have the impression that SVR4.0 will at least have the terminal handler
>converted to STREAMS (this seems to imply that the M_DELIM control packets
>are being put back in),

Not necessarily.  A "read" on a stream can be in message-nondiscard
or message-discard mode, in which case, assuming you put one line in
canonical mode into one message, a "read" will only read a single
line.