Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!uunet!seismo!sundc!sun!gorodish!guy
From: guy%gorodish@Sun.COM (Guy Harris)
Newsgroups: comp.unix.questions
Subject: Re: System V manuals (was Re: What real non-UNIX 'C' compilers...)
Message-ID: <31166@sun.uucp>
Date: Sun, 18-Oct-87 02:34:28 EDT
Article-I.D.: sun.31166
Posted: Sun Oct 18 02:34:28 1987
Date-Received: Sun, 18-Oct-87 22:53:05 EDT
References: <855@sugar.UUCP> <29930@sun.uucp> <867@sugar.UUCP> <30458@sun.uucp> <139@nusdhub.UUCP>
Sender: news@sun.uucp
Lines: 52

> > It reads whatever data is at the stream had for the stream that refers to
> > the multiplexor (there is no such thing as a "multiplexing stream head";
> > multiplexors are drivers at the bottom of the stream).  What did you
> > *think* it did?

> [user process]
> 	|
> [Multiplexor Driver]
>           |   |   |
> module:   A   B & C
> 
> etc. ad nasuim.

For some reason, probably to simplify the diagram, they omitted the stream head
from this diagram.  It's still there; it's *always* there in *any* stream.

> Perhaps multiplexing is why ther is a poll() system call.
> If the multiplexing were only at the bottom, what would this be for?

Nope.  "poll" is just 4.2BSD's "select" with a propellor beanie.  It has
nothing to do with STREAMS multiplexor drivers; it is used for "multiplexing",
in a sense.  It is used if a program wants to manage several streams,
"multiplexing", if you will, its time between servicing those streams.

"poll" is given a set of cookies, each one of which expresses interest in the
state of various file descriptors that refer to streams.  The caller of "poll"
can ask whether a "read" or "getmsg" can be done on the stream without blocking
(i.e., data is present at the stream head); whether a "write" or "putmsg" can
be done on the stream without blocking (i.e., there is not so much data queued
somewhere that flow control would cause a "write" or "putmsg" to block); or
whether a high-priority message is present at the stream head.  (These provide
basically the same functionality as the "read", "write", and "exceptional
condition" bit masks for the "select" system call.)

It blocks until at least one of the streams referred to is in the state or
states for which interest has been expressed for that stream.  It will also
return if one of the streams gets an error or hangup message.

Programs that use "poll" (or "select") are often written as a big loop with a
"poll" at the top.  If the "poll" returns, it means that some amount of I/O can
be done on some subset of the streams in question without blocking.  It does
whatever I/O it can, and returns to the top of the loop.  The program will
typically put descriptors on which "write"s or "putmsg"s are to be done in
non-blocking mode, so that you can attempt to write as much data as possible,
and the system will only write as much data as can be written without blocking
and tell you how much that was.  This is often a good idea for streams on which
"read"s or "getmsg"s are to be done, as well, since "poll" (or "select") can
return because there is data to be read, but the data could be flushed (due
e.g. to an M_FLUSH message going upstream) before the "read" is actually done.
	Guy Harris
	{ihnp4, decvax, seismo, decwrl, ...}!sun!guy
	guy@sun.com