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. 

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).

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.

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