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 5D430BC69 for ; Mon, 2 Jul 2007 18:44:55 +0200 (CEST) Received: from ipmail03.adl2.internode.on.net (ipmail03.adl2.internode.on.net [203.16.214.135]) by concorde.inria.fr (8.13.6/8.13.6) with ESMTP id l62GiqsJ015992 for ; Mon, 2 Jul 2007 18:44:54 +0200 X-IronPort-AV: E=Sophos;i="4.16,487,1175437800"; d="scan'208";a="110556800" Received: from ppp121-44-3-31.lns4.syd7.internode.on.net (HELO [192.168.1.201]) ([121.44.3.31]) by ipmail03.adl2.internode.on.net with ESMTP; 03 Jul 2007 02:14:51 +0930 Subject: Re: [Caml-list] unix.select + camlp4 From: skaller To: Anastasia Gornostaeva Cc: caml-list@inria.fr In-Reply-To: <20070702153934.GA1911@ermine.home> References: <20070701203044.GA4434@ermine.home> <200707012137.46921.jon@ffconsultancy.com> <20070701210125.GB4434@ermine.home> <1183342234.15100.6.camel@rosella.wigram> <20070702153934.GA1911@ermine.home> Content-Type: text/plain Date: Tue, 03 Jul 2007 02:44:50 +1000 Message-Id: <1183394690.11863.22.camel@rosella.wigram> Mime-Version: 1.0 X-Mailer: Evolution 2.10.1 Content-Transfer-Encoding: 7bit X-Miltered: at concorde with ID 46892B85.002 by Joe's j-chkmail (http://j-chkmail . ensmp . fr)! X-Spam: no; 0.00; camlp:01 0100,:01 parses:01 non-blocking:01 parser:01 parser:01 camlp:01 parsers:01 ocaml:01 threading:01 haskell:01 stack:01 model:01 threads:01 jocaml:01 On Mon, 2007-07-02 at 19:39 +0400, Anastasia Gornostaeva wrote: > On Mon, Jul 02, 2007 at 12:10:34PM +1000, skaller wrote: > > On Mon, 2007-07-02 at 01:01 +0400, Anastasia Gornostaeva wrote: > > > On Sun, Jul 01, 2007 at 09:37:46PM +0100, Jon Harrop wrote: > > > > > I dont understand: Try: > > > 1) It receives "1-2+3*" and parses it. > > > 2) Later it receives "4" and continues parsing. > > > > > > I want to get non-blocking parser. How to implement? > > > > Put the parser in a thread, select in another thread. > > Use Stream.from f for the parser. Write f to get characters > > using the Event module, send the characters from the other thread > > after select makes a channel active. > > It looks awful if you want to run houndreds streams/connections. > It is easier to run a connection with a parser in separate thread. > So, camlp4 cannot be nonblocking parser.. bad. This problem is not restricted to parsers .. it's a general problem with Ocaml and also C, C++, and most other languages. My language Felix solves this problem for procedures with user space threading .. but it doesn't work with functions. [And the builtin GLR parser is purely functional:] Other languages like Scheme and I think Haskell and MLton have more general solutions because they're not restricted to the archaic concept of a linear stack. You can certainly write code using continuation passing style to work around this deficiency in most languages, but you can't work around someone else's code that doesn't use this style. The general model of using 'threads' is the only solution, however OS threads are too general and too slow for large numbers, and they're needlessly asynchronous when all you often want is control inversion (though in your case, you're using 'select' so you do want asynchronicity). JoCaml is worth looking at for another approach.. but the bottom line is if you're using the usual parser products around, the only way to control invert the 'get_token' callback is by using a pair of threads implementing a client/server model, and allowing the OS to control invert the threads by stack swapping. -- John Skaller Felix, successor to C++: http://felix.sf.net