Re: [Caml-list] Re: Select on channels (again)

[skaller <skaller@users.sourceforge.net>]

On Wed, 2006-08-23 at 12:31 -0700, Nathaniel Gray wrote:
> On 8/22/06, skaller <skaller@users.sourceforge.net> wrote:

> > The problem would be the semantics you indicate above.
> > You're going to get non-blocking behaviour when the
> > channels are quiet, but once there is some data,
> > you get blocking.
> 
> I don't follow you.  Are you talking about input or output channels?
> Can you give an example?

Sure .. two sockets, with integers coming down them encoded as
characters .. perhaps a CSV file.

The sockets are quiet. Then some data comes down one,
and you go off and try to read an integer .. but half way
through you run out of data and block.

Now a whole stream of integers comes down the OTHER socket.
Bad luck, your thread is blocked waiting on data from the
first socket.

Select or not .. buffering or not: you might as well have just 
picked a socket and done a blocking read on it.

Unless you can *guarantee* some invariant is preserved,
you've achieved nothing.

The correct way to use select is in conjunction
with a polling loop that does non-blocking I/O. 

Polling all your channels without blocking is what you want,
that way you read or write data efficiently.

But such a polling loop wastes cycles and isn't very responsive,
so you use select() to skip over polling channels that cannot 
be ready, if that happens to be all of them, you might as well
block until the situation changes, if some channels are
ready you can go off and try I/O on them, and not bother
with the non-ready channels.

The key thing here is that select is an optimisation:
the IMPORTANT point is that the polling must use
non-blocking I/O.

Note: just because select() indicates an fd is ready
doesn't mean it is. There's no assurance even one byte
can be read or written.

Select() is just like a condition variable -- you have
to assume spurious wakeups. Both provide a way to know
when and what to check which avoids excessive polling.
Select, like condition variables, are just hints to
improve response time and resource utilisation:
they have no semantics. (More precisely the delivery
of a signal MUST wake up the client but the converse
isn't required).

The important semantics are in YOUR code: the condition 
check must not block, similarly, I/O must not block.

So basically doing blocking I/O in conjunction
with select makes no sense.

IF you had some known semantics such as that
messages were of bounded length and transmitted
in bounded time .. select would be useful, since
blocking operations would block only for bounded time,
in which case they're not blocking at all.

So you are right, a channel based select COULD be useful,
given such a constraint, however it doesn't break the
rule above, since blocking for a bounded time is 
semantically a non-blocking operation: an operation
is only blocking if it can block for an unbounded time.

For this reason most programmers consider all disk I/O
as non-blocking .. even though the OS kernel may
not agree with this interpretation :)


-- 
John Skaller <skaller at users dot sf dot net>
Felix, successor to C++: http://felix.sf.net