Version française
Home     About     Download     Resources     Contact us    

This site is updated infrequently. For up-to-date information, please visit the new OCaml website at

Browse thread
[Caml-list] Re: mod_ocaml 0.6.0 feedback
[ Home ] [ Index: by date | by threads ]
[ Search: ]

[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
Date: -- (:)
From: Xavier Leroy <xavier.leroy@i...>
Subject: Re: [Caml-list] Re: mod_ocaml 0.6.0 feedback
> The reason for not supporting Apache 2 is simply that I don't know
> much about how to port Apache 1.x code to Apache 2. Also I'm a bit
> worried about threading issues. (I've CC'd this to the caml-list -
> can anyone comment?)

I'm assuming Apache 2.0 is multithreaded, so that the Caml functions
could possibly end up being called by several (POSIX) threads
simultaneously.  The following should work:
- Put a mutex around calls to the "callback*" functions
  (those that call back into Caml from C), so that Caml execution
  is entirely serialized.
- Do *not* use Caml threads in your Caml code, and do not link the
  Caml code with the Caml threading libraries.  Currently,
  Caml threads and callbacks don't work together.  I'll have to
  address this at some point in the future.

> Unfortunately Dynlink doesn't provide a way to unload modules (can
> anyone on caml-list comment?).

This is correct, but there are no easy ways to do that.  Unloading
*safely* a piece of dynamically-linked code would require scanning the
whole heap, making sure that no live function value refers to that
piece of code.  The alternative would be to let the GC find out the
dead pieces of code, but again this is problematic since code blocks
are not garbage-collected in the current implementation.

- Xavier Leroy

To unsubscribe, mail Archives:
Bug reports: FAQ:
Beginner's list: