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.1 required=5.0 tests=AWL,BANG_GUAR 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 45BC5BC6A for ; Fri, 25 Aug 2006 03:56:01 +0200 (CEST) Received: from ash25e.internode.on.net (ash25e.internode.on.net [203.16.214.182]) by nez-perce.inria.fr (8.13.6/8.13.6) with ESMTP id k7P1twhA021002 for ; Fri, 25 Aug 2006 03:56:00 +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 k7P1tY5s024018; Fri, 25 Aug 2006 11:25:35 +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> <1156314944.7834.46.camel@rosella.wigram> <1156397869.16998.122.camel@rosella.wigram> Content-Type: text/plain Date: Fri, 25 Aug 2006 11:55:34 +1000 Message-Id: <1156470934.20759.166.camel@rosella.wigram> Mime-Version: 1.0 X-Mailer: Evolution 2.6.1 Content-Transfer-Encoding: 7bit X-Miltered: at nez-perce with ID 44EE58AE.001 by Joe's j-chkmail (http://j-chkmail.ensmp.fr)! X-Spam: no; 0.00; semantics:01 bounded:01 bounded:01 ocaml:01 printf:01 sscanf:01 ocaml:01 2006:98 sourceforge:01 sourceforge:01 wrote:01 wrote:01 parsed:01 caml-list:01 terminate:01 On Thu, 2006-08-24 at 12:06 -0700, Nathaniel Gray wrote: > On 8/23/06, skaller wrote: > > > > IF you had some known semantics such as that > > messages were of bounded length and transmitted > > in bounded time .. select would be useful, since > > blocking operations would block only for bounded time, > > in which case they're not blocking at all. > > That's exactly what I'm talking about. There are plenty of cases > where such assumptions are justified, including IPC on a single > machine or communication on a small trusted network. Select on > channels is no more or less useful than regular select, other than the > fact that it makes it possible to use OCaml functions that only > operate on channels. This is true, and in C it is the same: printf(...) sscanf(... ) are both going to block, possibly for a bounded time if they're only called when you know the underlying fd has, at least temporarily, enough throughput to allow the formatting algorithms to terminate. The thing is, you can already do this, guaranteed! It is rather heavy though: you make two pthreads and read one fd in each, then send the results down a single Event channel: the user code can then read the parsed objects in sequence, blocking until the first is available, then blocking until the second is available. The point is that although this is heavy, it is guaranteed to work, so using Event module with pthreads is actually easier to reason about. If you would like to do this without the cost of spawning pthreads .. then you need to use Felix, not Ocaml :) -- John Skaller Felix, successor to C++: http://felix.sf.net