English version
Accueil     À propos     Téléchargement     Ressources     Contactez-nous    

Ce site est rarement mis à jour. Pour les informations les plus récentes, rendez-vous sur le nouveau site OCaml à l'adresse ocaml.org.

Browse thread
[Caml-list] Delaying module initialization
[ Home ] [ Index: by date | by threads ]
[ Search: ]

[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
Date: 2004-03-29 (06:10)
From: skaller <skaller@u...>
Subject: Re: [Caml-list] Delaying module initialization
On Mon, 2004-03-29 at 13:36, Jacques Garrigue wrote:
> From: skaller <skaller@users.sourceforge.net>
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