From: Sam on
Dances With Crows writes:

> Steven Woody staggered into the Black Sun and said:
>
>> It's okay to know Linux doesn't support POSIX streams.
>
> I don't know for sure, since I've actually never had to use those, but
> I'm guessing it doesn't based on the return values and gcc warnings
> produced by the isastream() and fattach() functions. (Not all of POSIX
> is implemented, just the parts that the kernel and glibc people thought
> were useful and nifty.) What exactly are these things supposed to *do*
> for a programmer, anyway? It's not immediately obvious like fcntl() and
> flock().

It's a forgettable System V protocol stack. A very oversimplified answer is
that userspace sets up a network connections by stacking protocol modules
into a "stream", and the individual modules have a rigid protocol for
talking to each other, and flinging bits of datum up/downstream. I don't
recall, off the top of my head, whether current Solaris still implements the
BSD socket interface as a wrapper for a STREAM. It used to, some time ago.

Which led to such helpful situations like when a process binds a server
socket, listen()s on it, then forks and execs another executable, the new
executable can't actually call accept() to receive new connections, because
its userspace has no clue what the stream socket is all about. You'd have to
call some obscure function to resynchronize the socket metadata, before the
new process can accept() connections. That, anyway, is my hazy recollection
of days long gone by.

>> And, I also found the s_pipe() function mentioned in the text also
>> missed in Linux, does that mean Linux doesn't support stream pipe
>> either?
>
> What is a "stream pipe"? Pipes are supported. The default for opening

For all intents and purposes, what used to be called a stream pipe, created
via s_pipe(), is pretty much equivalent to socketpair() these days. Or,
setting up a pair of AF_UNIX sockets, talking to each other. That's your
stream pipe right there.