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

["Nathaniel Gray" <n8gray@gmail.com>]

On 8/22/06, skaller <skaller@users.sourceforge.net> wrote:
> On Tue, 2006-08-22 at 22:16 -0700, Nathaniel Gray wrote:
>
> > You're right -- *truly* non-blocking Marshal.from_channel requires
> > more than select on channels, but it's often good enough to know if
> > there's any data in the channel at all.  It's often acceptable to
> > block long enough for the *rest* of a partial message to arrive but
> > unacceptable to block indefinitely waiting for a new message to
> > arrive.
> >
> > In any case, Marshal.from_channel isn't the only reason one might want
> > select on channels.  Is this something the dev team would be willing
> > to accept as a patch?  It's a pretty trivial thing to implement.
>
> 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?

I suppose that on output channels you might not want to try to write
to the buffer if the fd is blocked, but you can always use plain old
Unix.select to check for that condition.

> It sounds hard to reason about the
> properties of a system with these semantics:
> you can already get the fd of a channel and select
> on it, and have a similar problem (fd is quiet,
> the buffer has data).

The semantics would be the same as the normal select.  If an
in_channel is ready it means at least one byte can be read without
blocking.  If an out_channel is ready then at least one byte can be
written without blocking.

> An alternative may be a pair of functions:
>
>         bytes_of_in_channel: in_channel -> int
>         bytes_of_out_channel: out_channel -> int
>
> which tell how much data remains in the buffers,
> you could use that in conjunction with Unix.select.

That would be sufficient, but it would end up being a bit deceptive --
both sizes would be limited by the buffer sizes involved.

There are lots of ways to skin this particular cat.  I chose
channel_select because it reveals very little about implementation
details like buffer sizes, which seems in keeping with the rest of the
channel API.  Another option would be {in,out}_channel_ready, upon
which one could easily build channel_select.

Cheers,
-n8

-- 
>>>-- Nathaniel Gray -- Caltech Computer Science ------>
>>>-- Mojave Project -- http://mojave.cs.caltech.edu -->