Version française
Home     About     Download     Resources     Contact us    
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: -- (:)
From: Jacques Garrigue <garrigue@k...>
Subject: Re: [Caml-list] Delaying module initialization
From: skaller <skaller@users.sourceforge.net>
> On Sun, 2004-03-28 at 20:34, Jacques Garrigue wrote:
> 
> > > The former is interesting but not industrially satisfying
> > > because it doesn't allow dynamic loading of interfaces
> > > to C, which must be native code.
> > 
> > But, this is plain wrong: since 3.04 you can dynamically load C stubs
> > through dynamically loading a bytecode library.
> 
> This I do not understanding but I seem to have missed something. 
> 
> Are you saying I can write a module X.ml which wraps a C library 
> with function f(), and another Y.ml which wraps a different 
> function f() of another  shared library, and then write a 
> program which can be run like:
> 
> loadit X
> loadit Y
> 
> where the first script invokes X's f() and the second Y's f()?

You are mixing here different problems, and I can interpret your
question in several ways.

If your question is: can I load simultaneously several shared
libraries containing some C functions with the same name, then the
answer is probably: only under windows. But I did not try, so maybe it
works on other systems too, or maybe it doesn't work on windows for
some reason.  This is a question of C binary namespace, flat or
hierarchical.  To simplify writing libraries, ocaml uses the flat
model (more usual on Unix), but windows happens to support only the
hierarchical model.

If it is: can I choose at runtime which shared library to load, and
provide a unified interface independent of the library, then the
answer is yes. IIRC, CamlGL uses that to allow choosing your openGL
library at runtime. There are some pitfalls, like the fact you need to
provide a different stub library (both C and caml part) for each
shared library you want to load, or the fact you cannot unload a
library. But in my opinion the main problem is that different
libraries shall probably have different signatures under the refined
ocaml type system, so that it will be very hard to use a unified
interface (we have already trouble with the different version of Gtk+-2.x).

If it is: can I dynamically generate stubs for a shared library,
compile them (both C and caml part) and load the library in the same
program, then this should be yes too.  Automatizing all this might be
a lot of work, but there is no theoretical limitation.  Again there
may be problems with name spaces, but if this is really your concern
you just have to change one line in ocamlrun sources to use the
hierarchical model.

> If dynamic loading is as Jacques suggests, then it would
> seem mod_caml has a strange design..
> 
> Given an HTML page containing some Caml script
> which in invokes some functions which wrap
> Perl modules .. the whole thing should be 
> dynamic automatically.
> 
> I can't see how 'initialising all the Perl modules'
> could happen. I'd have to try extremely hard to even
> think about how to make that happen.

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. This is _not_ a problem of dynamic loading, and this could
actually change the semantics of the language, since initializing one
module might force initializing another one in its turn, and as a result
module initialization might not be sequential.  On the other hand, this
should not be too hard to do with bytecode, at least java style: parse
the .cma's, but do not load their dependencies immediately.

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.

Jacques Garrigue

-------------------
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