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 nez-perce.inria.fr (nez-perce.inria.fr [192.93.2.78]) by yquem.inria.fr (Postfix) with ESMTP id DE54BBC6C for ; Tue, 22 Aug 2006 10:10:38 +0200 (CEST) Received: from mallaury.nerim.net (smtp-102-tuesday.noc.nerim.net [62.4.17.102]) by nez-perce.inria.fr (8.13.6/8.13.6) with ESMTP id k7M8Ac5M031103 for ; Tue, 22 Aug 2006 10:10:38 +0200 Received: from karryall.dnsalias.org (karryall.dnsalias.org [213.41.240.180]) by mallaury.nerim.net (Postfix) with ESMTP id 8D3E44F3C0; Tue, 22 Aug 2006 10:10:20 +0200 (CEST) Received: by karryall.dnsalias.org (Postfix, from userid 500) id CB1B873E35F; Tue, 22 Aug 2006 10:10:25 +0200 (CEST) From: Olivier Andrieu MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17642.48113.637250.34242@karryall.dnsalias.org> Date: Tue, 22 Aug 2006 10:10:25 +0200 To: "Nathaniel Gray" Cc: Caml Mailing List Subject: Re: [Caml-list] Re: Select on channels (again) In-Reply-To: References: X-Mailer: VM 7.19 under Emacs 21.4.1 X-Miltered: at nez-perce with ID 44EABBFE.000 by Joe's j-chkmail (http://j-chkmail.ensmp.fr)! X-Spam: no; 0.00; andrieu:01 oandrieu:01 unix:01 unix:01 ocaml:01 descriptors:01 ocaml:01 buffer:01 buffer:01 non-blocking:01 2006:98 wrote:01 marshal:01 marshal:01 caml-list:01 Nathaniel Gray [Monday 21 August 2006] : > > 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. Indeed, Marshal.from_channel would block, but it's not the only way to read a marshalled value: cf. Marshal.header_size and Marshal.data_size. With these, you can read your marshalled value from file_descr into a buffer in a non-blocking, select-compatible way and then use Marshal.from_string. -- Olivier