On 8/22/06, Jacques Garrigue <garrigue@math.nagoya-u.ac.jp> wrote:
> (I didn't follow the discussion, so I may misunderstand...)
>
> The problem with Marshal.from_channel seems independent of channel
> buffering. The point is that Marshal.from_channel cannot work in
> non-blocking mode, as it doesn't know in advance how many bytes it
> will need to obtain a well-formed value. The only way I see is to do
> the buffering yourself, and extract the data using Marshal.from_string
> and Marshal.total_size.

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.

Cheers,
-n8

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