SVR4 STREAMS (for example LiS)

Hello All!

I have little bit theoretical question. As usual ;-)

From what ever piece of doc I see says that STREAMS are good. They are part of SUS (at least v3 has them).
Sun's docs reffering only cases when one may want to use them. This was the first pointer to problems: docs are missing the
"dark side" of STREAMS.

Can anyone give any pointers to information why STREAMS are _not_
part of Linux kernel yet?
(Besides that no-one needs/merged it in kernel ;-) What kind of problems this implementation of I/O has? (Low performance and high latencies I expect - but what's else?)

Any sort of RTFM will be very appreciated.

Thanks in advance.

Streams are an extension of buffered I/O implimented by the 'C' runtime library. Streams really have nothing to do with the internal workings of kernel I/O. As far as kernel I/O goes, one reads() and writes() from user-space.

That said, the kernel provides getpmsg and putpmsg functions to support streams. You really can't do much more for streams inside the kernel and be efficient.

Cheers,
Dick Johnson
Penguin : Linux version 2.4.20 on an i686 machine (797.90 BogoMips).
Note 96.31% of all statistics are fiction.

Actually, SysV Streams do.

An ex, for openning a pty, on svr4:
fds = open(pts_name, O_RDWR)
ioctl(fds, I_PUSH, "ptem")
ioctl(fds, I_PUSH, "ldterm")
ioctl(fds, I_PUSH, "ttcompat")

Where ptem, ldterm, ttcompat work as independent modules converting the stream, resulting in a pseudo-terminal implementation.

New programs should just use openpty directly, and let libc take care of the actual implementation.

Also, BSD sockets were implemented using streams also, thus the compatibility libraries.

Anyway, I see no point in caring wether streams are used or not in normal programs.

Regards,
Luciano Rocha