Browse thread
Native executable symtable
[
Home
]
[ Index:
by date
|
by threads
]
[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
| Date: | -- (:) |
| 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 engineerable. 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