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: 2003-08-19 (13:16)
From: Richard Jones <rich@a...>
Subject: [Caml-list] Re: mod_ocaml 0.6.0 feedback
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.


Richard Jones.
Merjis Ltd. - all your business data are belong to you.
"My karma ran over your dogma"

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