mitchell@cadovax.UUCP (Mitchell Lerner) (01/22/87)
--
Mitchell Lerner
# {ucbvax,ihnp4,decvax}!trwrb!cadovax!mitchell
# cadovax!mitchell@ucla-locus.arpamitchell@cadovax.UUCP (Mitchell Lerner) (01/22/87)
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?
--
Mitchell Lerner
# {ucbvax,ihnp4,decvax}!trwrb!cadovax!mitchell
# cadovax!mitchell@ucla-locus.arpagwyn@brl-smoke.UUCP (01/24/87)
In article <1342@cadovax.UUCP> mitchell@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).
guy@gorodish.UUCP (01/26/87)
>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.