Mailing list for all users of the OCaml language and system.
 help / color / mirror / Atom feed
From: skaller <skaller@users.sourceforge.net>
To: Richard Jones <rich@annexia.org>
Cc: caml-list <caml-list@inria.fr>
Subject: Re: [Caml-list] Native executable symtable
Date: 22 Nov 2004 07:29:51 +1100	[thread overview]
Message-ID: <1101068990.22082.60.camel@pelican.wigram> (raw)
In-Reply-To: <20041121155909.GA18549@annexia.org>

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




  reply	other threads:[~2004-11-21 20:30 UTC|newest]

Thread overview: 34+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-11-11 10:18 Alex Baretta
2004-11-11 10:39 ` [Caml-list] " Nicolas Cannasse
2004-11-11 11:09   ` Luca Pascali
2004-11-11 11:55     ` Keith Wansbrough
2004-11-11 12:09       ` Luca Pascali
2004-11-11 12:28         ` Keith Wansbrough
2004-11-11 12:42           ` Luca Pascali
2004-11-11 16:09             ` Richard Jones
2004-11-20 15:44               ` Luca Pascali
2004-11-20 16:03                 ` malc
2004-11-20 18:01                   ` Alex Baretta
2004-11-20 18:06                     ` malc
2004-11-20 18:53                       ` Alex Baretta
2004-11-20 19:17                         ` malc
2004-11-20 20:07                           ` Ritesh Kumar
2004-11-20 22:43                           ` The madness of ignoring people Vincenzo Ciancia
2004-11-20 23:10                             ` [Caml-list] " malc
2004-11-20 23:25                               ` Vincenzo Ciancia
2004-11-21 12:51                             ` skaller
2004-11-21 14:14                               ` Vincenzo Ciancia
2004-11-21 14:30                                 ` malc
2004-11-21  3:37                           ` [Caml-list] Native executable symtable skaller
2004-11-21 15:59                           ` Richard Jones
2004-11-21 20:29                             ` skaller [this message]
2004-11-21 20:39                               ` malc
2004-11-21 23:30                               ` Richard W.M. Jones
2004-11-22  3:25                                 ` skaller
2004-11-21 20:42                             ` Jean-Marie Gaillourdet
2004-11-21 18:31                               ` Ritesh Kumar
2004-11-21 23:33                                 ` Richard Jones
2004-11-21 21:15                               ` skaller
2004-11-11 16:23 ` David Brown
2004-11-11 17:27 ` Xavier Leroy
2004-11-11 18:48   ` Alex Baretta

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1101068990.22082.60.camel@pelican.wigram \
    --to=skaller@users.sourceforge.net \
    --cc=caml-list@inria.fr \
    --cc=rich@annexia.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox