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.2 required=5.0 tests=AWL,DNS_FROM_RFC_ABUSE 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 DC6A3BCAC for ; Tue, 22 Aug 2006 10:21:59 +0200 (CEST) Received: from kurims.kurims.kyoto-u.ac.jp (kurims.kurims.kyoto-u.ac.jp [130.54.16.1]) by nez-perce.inria.fr (8.13.6/8.13.6) with ESMTP id k7M8Lvnv000305 for ; Tue, 22 Aug 2006 10:21:59 +0200 Received: from localhost (orion [130.54.16.5]) by kurims.kurims.kyoto-u.ac.jp (8.13.7/8.13.7) with ESMTP id k7M8LguD000880; Tue, 22 Aug 2006 17:21:42 +0900 (JST) Date: Tue, 22 Aug 2006 17:21:38 +0900 (JST) Message-Id: <20060822.172138.82692882.garrigue@math.nagoya-u.ac.jp> To: n8gray@gmail.com Cc: caml-list@yquem.inria.fr Subject: Re: [Caml-list] Re: Select on channels (again) From: Jacques Garrigue In-Reply-To: References: X-Mailer: Mew version 4.2 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Miltered: at nez-perce with ID 44EABEA5.000 by Joe's j-chkmail (http://j-chkmail.ensmp.fr)! X-Spam: no; 0.00; unix:01 unix:01 ocaml:01 descriptors:01 ocaml:01 buffer:01 non-blocking:01 well-formed:01 wrote:01 marshal:01 marshal:01 caml-list:01 functions:01 referenced:01 data:02 From: "Nathaniel Gray" > On 8/21/06, Jonathan Roewen wrote: > > Why can't you just use the unix file opening functions since you're > > using unix select? And if you need the ocaml in/out channels, convert > > the unix file descriptors to ocaml ones instead of the other way > > around. Seems simple enough to me. > > It sounds simple but doesn't work. If select tells you a file > descriptor doesn't have data waiting you can't be sure there isn't > still data in the corresponding channel's buffer. See the thread that > I referenced for a good discussion of why this is annoying. For one > thing, it makes it impossible to use Marshal.from_channel without > potentially blocking. (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. Jacques Garrigue