From mboxrd@z Thu Jan 1 00:00:00 1970 Received: (from majordomo@localhost) by pauillac.inria.fr (8.7.6/8.7.3) id IAA27642; Mon, 29 Mar 2004 08:10:23 +0200 (MET DST) X-Authentication-Warning: pauillac.inria.fr: majordomo set sender to owner-caml-list@pauillac.inria.fr using -f 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 IAA27604 for ; Mon, 29 Mar 2004 08:10:22 +0200 (MET DST) Received: from smtp1.adl2.internode.on.net (smtp1.adl2.internode.on.net [203.16.214.181]) by concorde.inria.fr (8.12.10/8.12.10) with ESMTP id i2T6AHHd005554 for ; Mon, 29 Mar 2004 08:10:19 +0200 Received: from [192.168.1.200] (ppp113-158.lns1.syd3.internode.on.net [150.101.113.158]) by smtp1.adl2.internode.on.net (8.12.9/8.12.9) with ESMTP id i2T6ADwn087760; Mon, 29 Mar 2004 15:40:14 +0930 (CST) Subject: Re: [Caml-list] Delaying module initialization From: skaller Reply-To: skaller@users.sourceforge.net To: Jacques Garrigue Cc: skaller@users.sourceforge.net, caml-list In-Reply-To: <20040329123654I.garrigue@kurims.kyoto-u.ac.jp> References: <1080403497.4708.160.camel@pelican.wigram> <20040328193438O.garrigue@kurims.kyoto-u.ac.jp> <1080517867.4708.174.camel@pelican.wigram> <1080520544.4708.188.camel@pelican.wigram> <20040329123654I.garrigue@kurims.kyoto-u.ac.jp> Content-Type: text/plain Message-Id: <1080540612.4708.219.camel@pelican.wigram> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 (1.2.2-4) Date: 29 Mar 2004 16:10:13 +1000 Content-Transfer-Encoding: 7bit X-Miltered: at concorde by Joe's j-chkmail ("http://j-chkmail.ensmp.fr")! X-Loop: caml-list@inria.fr X-Spam: no; 0.00; caml-list:01 sourceforge:01 2004:99 jacques:01 sourceforge:01 faq:01 jacques:01 initializing:01 initialized:01 dynamically:01 order':99 end-up:01 initializing:01 workarounds:01 dynamically:01 Sender: owner-caml-list@pauillac.inria.fr Precedence: bulk X-Status: X-Keywords: X-UID: 404 On Mon, 2004-03-29 at 13:36, Jacques Garrigue wrote: > From: skaller [] Thanks for that long explanation! Put in FAQ? > > If dynamic loading is as Jacques suggests, then it would > > seem mod_caml has a strange design.. > Here we enter another problem: ocaml has dynamic loading, but not > auto-loading/initializing. Looks like lots of people would want to > have that: a module would be initialized only when one of its members > is used. Yes: this seems to imply the modules are pre-linked instead of loaded dynamically. > This is _not_ a problem of dynamic loading, and this could > actually change the semantics of the language, Indeed, and Xaviers solution is the way to handle this, as in C++ where the trick originates and has an interesting encoding, but the bottom line is: if you want to control 'initialisation order' make the 'initialisation' a user defined function and call it. > Without auto-loading, you end-up loading everything in your name > space; so that would result in initializing all Perl modules if you > are initializing them on load. Some workarounds have already been > suggested to delay this initialization. Indeed but it seems the wrong solution to pre-load every module you might want to use. The only viable universal solution is to load dynamically the same way Perl itself does. More precisely I'd envisage the following design: (1) Core modules are linked statically. Example: some module used for formatting HTML is likely to be needed in every script. (2) A user defined list of modules is loaded at run time initially. This introduces a delay processing user script in an HTML page, but it will crash the processes early if there is a failure. On some architectures, it may be possible to do this ONCE and suspend the process, then fork the processs for the client page, greatly speeding up service of the client page by reducing initialisation to copying on demand performed by the Virtual Memory system. I don't know if Apache can do this .. (3) Other modules are loaded on demand. This should be used where there is some conditional execution, and must be where there is dynamic module name determination. This technique is the least reliable, but avoids loading modules that might not be used. An interesting module set is: ones to handle differences is the client browser. EG: a module to uniformly handle generation of *different* HTML for Mozilla or Internet Explorer. Note by "load on demand" i do not mean 'pre-load and initialise on use' .. that's a separable technique that might be useful for (1) or (2) if there is a lot of 'pieces' of initialisation needed for different functions, and a lot of functions, only some of which are likely to be used in a given invocation. The three kinds of module are specified: (1) At mod_caml construction time in the actual Ocaml namespace: static linkage. (2) In a configuration file. Load time linkage. (3) In the client HTML page. Run time linkage. -- 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 ------------------- To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/ Beginner's list: http://groups.yahoo.com/group/ocaml_beginners