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=1.6 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 382DEBC96 for ; Wed, 23 Aug 2006 07:16:56 +0200 (CEST) Received: from wx-out-0506.google.com (wx-out-0506.google.com [66.249.82.236]) by nez-perce.inria.fr (8.13.6/8.13.6) with ESMTP id k7N5GtUO006085 for ; Wed, 23 Aug 2006 07:16:55 +0200 Received: by wx-out-0506.google.com with SMTP id s6so2391044wxc for ; Tue, 22 Aug 2006 22:16:55 -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=e3tQ/Yw99FZK93r2BIImp0m/MXsqzNdL9saUqpE73Kb5BtqJehev0cLqdWIhPHm0ITfnImF3g9E/ZazxAnLLKcPlcQXhzwGkMR4030g1a3mf8XQREXTNOeAuLGj5/75vateuvE3xs/a+muQEF8vhDoeyLpNRk10YqypKlsfqB3Q= Received: by 10.90.113.20 with SMTP id l20mr2081agc; Tue, 22 Aug 2006 22:16:55 -0700 (PDT) Received: by 10.90.106.19 with HTTP; Tue, 22 Aug 2006 22:16:54 -0700 (PDT) Message-ID: Date: Tue, 22 Aug 2006 22:16:55 -0700 From: "Nathaniel Gray" To: "Jacques Garrigue" Subject: Re: [Caml-list] Re: Select on channels (again) Cc: caml-list@yquem.inria.fr In-Reply-To: <20060822.172138.82692882.garrigue@math.nagoya-u.ac.jp> 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> X-j-chkmail-Score: MSGID : 44EBE4C7.000 on nez-perce : j-chkmail score : X : 0/20 1 X-Miltered: at nez-perce with ID 44EBE4C7.000 by Joe's j-chkmail (http://j-chkmail.ensmp.fr)! X-Spam: no; 0.00; non-blocking:01 well-formed:01 non-blocking:01 unacceptable:01 trivial:01 cheers:01 wrote:01 marshal:01 marshal:01 partial:01 caml-list:01 dev:01 data:02 data:02 string:02 On 8/22/06, Jacques Garrigue 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 -->