From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on yquem.inria.fr X-Spam-Level: X-Spam-Status: No, score=0.9 required=5.0 tests=AWL,DNS_FROM_RFC_ABUSE, SPF_NEUTRAL autolearn=disabled version=3.1.3 X-Original-To: caml-list@yquem.inria.fr Delivered-To: caml-list@yquem.inria.fr Received: from nez-perce.inria.fr (nez-perce.inria.fr [192.93.2.78]) by yquem.inria.fr (Postfix) with ESMTP id AFB63BB83 for ; Wed, 23 Aug 2006 21:31:01 +0200 (CEST) Received: from wr-out-0506.google.com (wr-out-0506.google.com [64.233.184.238]) by nez-perce.inria.fr (8.13.6/8.13.6) with ESMTP id k7NJV0c1004719 for ; Wed, 23 Aug 2006 21:31:01 +0200 Received: by wr-out-0506.google.com with SMTP id i3so93182wra for ; Wed, 23 Aug 2006 12:31:00 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=VwOaZ7bYq2f1zKi47tKxHHB9a6uKo/cqvmlj5UHXjqEgK5quiNX6iwTA0uEPBUw20kD+I83Bma8ymtKR7gkpWWiETpEW0EmYZbYg05IGHP9VofUP3CcR8uO10a7LdoAEV23jhHJezDxIzcPEJ/lEzTO+hibynLc4D4XmYINy7rY= Received: by 10.90.119.15 with SMTP id r15mr275827agc; Wed, 23 Aug 2006 12:31:00 -0700 (PDT) Received: by 10.90.106.19 with HTTP; Wed, 23 Aug 2006 12:31:00 -0700 (PDT) Message-ID: Date: Wed, 23 Aug 2006 12:31:00 -0700 From: "Nathaniel Gray" To: skaller Subject: Re: [Caml-list] Re: Select on channels (again) Cc: "Jacques Garrigue" , caml-list@yquem.inria.fr In-Reply-To: <1156314944.7834.46.camel@rosella.wigram> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <20060822.172138.82692882.garrigue@math.nagoya-u.ac.jp> <1156314944.7834.46.camel@rosella.wigram> X-j-chkmail-Score: MSGID : 44ECACF4.000 on nez-perce : j-chkmail score : X : 0/20 1 X-Miltered: at nez-perce with ID 44ECACF4.000 by Joe's j-chkmail (http://j-chkmail.ensmp.fr)! X-Spam: no; 0.00; non-blocking:01 unacceptable:01 trivial:01 semantics:01 non-blocking:01 buffer:01 unix:01 semantics:01 buffer:01 byte:01 byte:01 unix:01 cheers:01 2006:98 deceptive:98 On 8/22/06, skaller 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 -->