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.0 required=5.0 tests=none autolearn=disabled version=3.1.3 X-Original-To: caml-list@yquem.inria.fr Delivered-To: caml-list@yquem.inria.fr Received: from concorde.inria.fr (concorde.inria.fr [192.93.2.39]) by yquem.inria.fr (Postfix) with ESMTP id 90E8BBC89 for ; Wed, 23 Aug 2006 08:36:16 +0200 (CEST) Received: from ash25e.internode.on.net (ash25e.internode.on.net [203.16.214.182]) by concorde.inria.fr (8.13.6/8.13.6) with ESMTP id k7N6aEW8010748 for ; Wed, 23 Aug 2006 08:36:15 +0200 Received: from rosella (ppp14-47.lns2.syd7.internode.on.net [59.167.14.47]) by ash25e.internode.on.net (8.13.6/8.13.5) with ESMTP id k7N6Ziam080677; Wed, 23 Aug 2006 16:05:45 +0930 (CST) (envelope-from skaller@users.sourceforge.net) Subject: Re: [Caml-list] Re: Select on channels (again) From: skaller To: Nathaniel Gray Cc: Jacques Garrigue , caml-list@yquem.inria.fr In-Reply-To: References: <20060822.172138.82692882.garrigue@math.nagoya-u.ac.jp> Content-Type: text/plain Date: Wed, 23 Aug 2006 16:35:44 +1000 Message-Id: <1156314944.7834.46.camel@rosella.wigram> Mime-Version: 1.0 X-Mailer: Evolution 2.6.1 Content-Transfer-Encoding: 7bit X-Miltered: at concorde with ID 44EBF75E.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 semantics:01 buffer:01 unix:01 2006:98 sourceforge:01 wrote:01 marshal:01 marshal:01 partial:01 caml-list:01 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 Felix, successor to C++: http://felix.sf.net