[Caml-list] Re: mod_ocaml 0.6.0 feedback

[Caml-list] Re: mod_ocaml 0.6.0 feedback

[Richard Jones]

On Tue, Aug 19, 2003 at 02:18:52PM +0200, Mikkel Fahn?e J?rgensen wrote:
> Hi Rich,
> 
> I can see that you  have started on a manual for mod_ocaml 0.6.0
> 
> This looks exciting - here is some feedback:
> 
> I'm only starting to work with Apache and I for one do not want to invest
> time on Apache 1.3 when Apache 2.0 is out. Apache 2.0 is required by the
> 'subversion' source control system - for that reason alone I think that many
> will choose Apache 2.0. Apache 2.0 is also the only viable choice for
> Windows servers.
> 
> So I suggest you focus on 2.0. I know the 1.3 market is larger, but by the
> time mod_ocaml matures, Apache 2.x will probably be the standard.
> Initially I wouldn't worry so much about full API coverage as the ability to
> actually run under Apache 2.

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

> Another thing:
> 
> Instead of registering 'run' you should register 'initialize', 'run' and
> 'shutdown'.
> You can probably get away without initialize as this is the main function
> running, but you do need a shutdown notification. Otherwise it isn't safe to
> cache handles.

Yup. Actually initialize isn't needed because you get that anyway when
you just put code at the top level of the module, but a shutdown or
on_unload function would be very useful.

> In the future you might want to add 'request_unload' and 'unload' so modules
> can be unloaded after sitting quiet for long periods of time where
> 'shutdown' is an unnegotiable termination of the module, such as a server
> termination.

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

If the concern is to free memory used by large structures, or to close
database handles, then the module could register some sort of timer
perhaps and do this themselves? The model I had in mind for database
handles would have a central Dbi module which would manage handing out
and reclaiming database handles, probably by handing out a temporary
value which represents the handle and reclaiming with a finaliser or
explicit "close" function.

Rich.

-- 
Richard Jones. http://www.annexia.org/ http://freshmeat.net/users/rwmj
Merjis Ltd. http://www.merjis.com/ - all your business data are belong to you.
"My karma ran over your dogma"

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

Re: [Caml-list] Re: mod_ocaml 0.6.0 feedback

[Alexander V. Voinov]

Hi Richard,

Richard Jones wrote:

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

In addition to what I've said recently, I got a bit more details why do we use 
Apache 2 in our company. The reason is threading: we use mod_python and don't 
want to maintain two installations of Python - with and without threading.

Alexander



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

Re: [Caml-list] Re: mod_ocaml 0.6.0 feedback

[Xavier Leroy]

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

Re: [Caml-list] Re: mod_ocaml 0.6.0 feedback

[Richard Jones]

It looks like I'll attempt an Apache 2 port then (given the number of
people nagging about it :-). But not until the weekend after next ...

Rich.

-- 
Richard Jones. http://www.annexia.org/ http://freshmeat.net/users/rwmj
Merjis Ltd. http://www.merjis.com/ - all your business data are belong to you.
"One serious obstacle to the adoption of good programming languages is
the notion that everything has to be sacrificed for speed. In computer
languages as in life, speed kills." -- Mike Vanier

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