From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from nez-perce.inria.fr (nez-perce.inria.fr [192.93.2.78]) by yquem.inria.fr (Postfix) with ESMTP id 4EBE2BC28 for ; Mon, 22 Nov 2004 04:25:13 +0100 (CET) Received: from pauillac.inria.fr (pauillac.inria.fr [128.93.11.35]) by nez-perce.inria.fr (8.13.0/8.13.0) with ESMTP id iAM3PBP2010253 for ; Mon, 22 Nov 2004 04:25:11 +0100 Received: from concorde.inria.fr (concorde.inria.fr [192.93.2.39]) by pauillac.inria.fr (8.7.6/8.7.3) with ESMTP id EAA28273 for ; Mon, 22 Nov 2004 04:25:11 +0100 (MET) Received: from smtp3.adl2.internode.on.net (smtp3.adl2.internode.on.net [203.16.214.203]) by concorde.inria.fr (8.13.0/8.13.0) with ESMTP id iAM3P8CX025294 for ; Mon, 22 Nov 2004 04:25:10 +0100 Received: from [192.168.1.200] (ppp217-171.lns1.syd3.internode.on.net [203.122.217.171]) by smtp3.adl2.internode.on.net (8.12.9/8.12.9) with ESMTP id iAM3P5OU058392; Mon, 22 Nov 2004 13:55:06 +1030 (CST) Subject: Re: [Caml-list] Native executable symtable From: skaller Reply-To: skaller@users.sourceforge.net To: "Richard W.M. Jones" Cc: caml-list In-Reply-To: <20041121233018.GB28429@annexia.org> References: <41935E30.3020104@yahoo.it> <20041111160949.GA13998@annexia.org> <419F664F.9020905@yahoo.it> <419F8664.8010501@baretta.com> <419F92C0.4010200@barettadeit.com> <20041121155909.GA18549@annexia.org> <1101068990.22082.60.camel@pelican.wigram> <20041121233018.GB28429@annexia.org> Content-Type: text/plain Message-Id: <1101093904.32394.162.camel@pelican.wigram> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 (1.2.2-4) Date: 22 Nov 2004 14:25:04 +1100 Content-Transfer-Encoding: 7bit X-Miltered: at nez-perce with ID 41A15C17.000 by Joe's j-chkmail (http://j-chkmail.ensmp.fr)! X-Miltered: at concorde with ID 41A15C14.000 by Joe's j-chkmail (http://j-chkmail.ensmp.fr)! X-Spam: no; 0.00; caml-list:01 symtable:01 sourceforge:01 wrote:01 wrote:01 bytecode:01 garbage:01 hacked:01 threads:01 bug:01 ocaml:01 bytecode:01 glebe:01 061:98 nsw:01 X-Spam-Checker-Version: SpamAssassin 3.0.0 (2004-09-13) on yquem.inria.fr X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=disabled version=3.0.0 X-Spam-Level: On Mon, 2004-11-22 at 10:30, Richard W.M. Jones wrote: > On Mon, Nov 22, 2004 at 07:29:51AM +1100, skaller wrote: > > However consider also a second problem with mod_caml: unloading. > > That's also essential for a long running process, and can't be done, > > even in the bytecode interpreter. There were *also* patches > > made for that (mods to the garbage collector to allow code > > to be collected). > > This isn't actually much of a problem with mod_caml. Deployments of > Apache should limit the number of HTTP requests that a single Apache > child can handle (MaxRequestsPerChild), after which the child exits. > This parameter is commonly set low with mod_perl also, since Perl has > several "issues" with running over long periods of time - it was > designed for short command line scripts after all. Ah, I see. So Apache is hacked to support broken module implementations.. :) There are other applicatins where this isn't possible, for example Felix was originally designed for a telco environment running say 20 CPU's, one thread per CPU, but millions of 'micro' threads (one per phone call). Restarting one thread in such an environment is possible but messy: you either need to make the microthreads mobile so you can move them from one CPU to another, or you have to be willing to wait 20 minutes whilst some person who likes long winded speeches (like me) finishes their call. (Or just disconnect them .. :) But basically you want to be able to run forever, even upgrading the call handling logic whilst the process is running. Total code use here isn't the issue so much as dynamic upgrading -- the main reason for unloading isn't to save memory, so much as to be sure no one is using an old version which happened to credit your account instead of debiting it due to a bug .. :) Anyhow to some extent I sympathise with the Ocaml team, in that just saying 'dynamic loading of native code' isn't a full answer. It promises something some programmer not fully understanding it may try to use only to find later that it isn't suitable because there are some hard to understand compromises (eg insecure unloading, different behaviour on different platforms, etc ..) BTW: is mod_caml bytecode that much of a performance issue for web service, compared with Python,Php, Perl etc? -- John Skaller, mailto:skaller@users.sf.net voice: 061-2-9660-0850, snail: PO BOX 401 Glebe NSW 2037 Australia Checkout the Felix programming language http://felix.sf.net