Streams Loop-Around driver...

[gwyn at brl-smoke.UUCP]

In article <1342 at cadovax.UUCP> mitchell at cadovax.UUCP (Mitchell Lerner) writes:
>Is the Loop-Around driver as shown in the the System V version 3 Streams 
>Programmers Guide in chapter 12 a way that I can do inter-process 
>communication?  I'm not sure that you can actualy open the driver from streams 
>on two separate processes (or more?) and have the driver connect the two 
>streams.  Can I use this type of Streams driver as the basis for an inter-
>process communications facility?

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).