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
Native executable symtable
[ Home ] [ Index: by date | by threads ]
[ Search: ]

[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
Date: 2004-11-21 (20:30)
From: skaller <skaller@u...>
Subject: Re: [Caml-list] Native executable symtable
On Mon, 2004-11-22 at 02:59, Richard Jones wrote:

> It'd be very useful for mod_caml - mod_caml uses Dynlink to load the
> "scripts" and handlers, and hence is limited to bytecode.  Native code
> dynamic linking would come in useful.  I'd rather it was part of core
> OCaml, or available as a separate library which didn't require OCaml
> itself to be recompiled.

You'll never convince a third party web site supplier to install 
a hacked version of Ocaml. It took ages to get Python server 
side available.

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

Finally, compare with Python where a superior implementation
called 'Stackless Python' which used continuation passing
was available for years. It inspired addition of a collector
and generators to be added to CPython, but because it would
require rewriting all the C extensions to obtain stackless
operations, the mods to the core interpreter never made it
into the main distribution.

My point is that if *you* were on the Ocaml team you'd
likely have a different perspective -- if you were going
to add a feature you'd want to be fairly sure the idea
was sound, complete, compatible, worthwhile -- and

I recently asked Hasn Boehm about unloading shared libraries
in C and C++ code and how that would operate with a
garbage collector.. he didn't see much hope of it ever working.
The fact is the changes needed to ISO C/C++ to even make
a *conservative* collector safe are non-trivial.

Felix actually *does* collect shared libraries, but it isn't
safe unless you limit data exchange very carefully to
ensure there can't be any dangling pointers, since the 
collector can't know about C pointers -- to C strings,
C functions, C++ vtables, and perhaps RTTI and exception
handling stuff..

So all of this seems quite difficult .. something
about the American saying "It works in practice" and
the Frenchman saying "Ah yes, but does it work in theory?"

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