[Caml-list] mod_caml's bytecode restriction due to Apache or just CGI dyn'linking?

[Caml-list] mod_caml's bytecode restriction due to Apache or just CGI dyn'linking?

[James Leifer]

Hi Richard et al,

I had a question about mod_caml's design.  I understand from the web
page that confining CGIs to bytecode isn't particularly onereous.  The
argument that most of the overhead is in talking with the db makes
perfect sense.

Yet for some applications, native would be useful.  For example, for
read-only data that changes only a few times a day, one can pack it in
Ocaml hash tables and get high perfomance queries right in Ocaml.  In
such a setup where Ocaml handles both the page layout *and* the
functionality of a db, native code looks a lot more attractive.

So... Is the limitation to use bytecode due to the desire to support
*dynamic* linking of CGIs or for other reasons?  If only the former,
then could one simply forgo this feature and *statically* link all the
natively compiled CGIs together with the mod_caml glue to make a
library that gets delivered to Apache?  If the price is that I have to
restart Apache when changing my CGIs I would be willing to pay it.

Kind regards,
-James

-------------------
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] mod_caml's bytecode restriction due to Apache or just CGI dyn'linking?

[Richard Jones]

On Sun, Jun 20, 2004 at 11:38:32PM +0200, James Leifer wrote:
> So... Is the limitation to use bytecode due to the desire to support
> *dynamic* linking of CGIs or for other reasons?

Basically, yes.  We would need a version of Dynlink supporting native
code.

> If only the former, then could one simply forgo this feature and
> *statically* link all the natively compiled CGIs together with the
> mod_caml glue to make a library that gets delivered to Apache?  If
> the price is that I have to restart Apache when changing my CGIs I
> would be willing to pay it.

'Tis possible.  However I don't have any applications where having
natively compiled CGIs would make any noticable difference, so this
isn't the sort of thing which Merjis would develop.  However if you
have patches ...

Rich.

-- 
Richard Jones. http://www.annexia.org/ http://www.j-london.com/
Merjis Ltd. http://www.merjis.com/ - improving website return on investment
MAKE+ is a sane replacement for GNU autoconf/automake. One script compiles,
RPMs, pkgs etc. Linux, BSD, Solaris. http://www.annexia.org/freeware/makeplus/

-------------------
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] mod_caml's bytecode restriction due to Apache or just CGI dyn'linking?

[Basile Starynkevitch [local]]

On Sun, Jun 20, 2004 at 11:38:32PM +0200, James Leifer wrote:

> I had a question about mod_caml's design.  I understand from the web
> page that confining CGIs to bytecode isn't particularly onereous. [...]
> 
> Yet for some applications, native would be useful.  For example, for
> read-only data that changes only a few times a day, one can pack it in
> Ocaml hash tables and get high perfomance queries right in Ocaml.  In
> such a setup where Ocaml handles both the page layout *and* the
> functionality of a db, native code looks a lot more attractive.
> 
> So... Is the limitation to use bytecode due to the desire to support
> *dynamic* linking of CGIs or for other reasons?  [...]

Sorry for the shameless plug - but I think that ocamljit can be used
to accelerate a bit such Ocaml propulsed web pages.

The GNUmakefile of ocamljit not only build the ocamljitrun executable
(a replacement for ocamlrun), but also a libcamljitrun.a which should
be a replacement for libcamlrun.a and hence might be useable (at least
on x86/linux) with mod_caml.

I suppose that mod_caml don't fork a process for every HTTP request
(in contrast to a pure CGI approach). This is particularily
appropriate for ocamljit since the overhead of bytecode to native
machine code translation is much less relevant here. (On pure CGI
short runs with ocamljitrun the translation time might be significant
- a few tenths of seconds for a "big" bytecode file).

Feel free to ask me about any practical problems of using ocamljit
with mod_caml (I didn't try, but believe it should be trivial).

Ocamljit is available on
http://cristal.inria.fr/~starynke/ocamljit.html and requires a recent
(ie CVS or future 3.08) ocaml system (source tree with built stuff)

Regards.
-- 
Basile STARYNKEVITCH -- basile dot starynkevitch at inria dot fr
Project cristal.inria.fr - (temporarily)
http://cristal.inria.fr/~starynke --- all opinions are only mine 

-------------------
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] mod_caml's bytecode restriction due to Apache or just CGI dyn'linking?

[James Leifer]

Richard Jones <rich@annexia.org> writes:

>> So... Is the limitation to use bytecode due to the desire to support
>> *dynamic* linking of CGIs or for other reasons?
>
> Basically, yes.  We would need a version of Dynlink supporting native
> code.

Hi Richard.

Thanks for your reply!

I'm confused whether "Bassically, yes" includes the part after my
"or" or not.

Let me see if I have this right: in order to support mod_caml's
current model of loading in new .cmo files, dynamic linking is
necessary, hence native is out of the question.

However, if one didn't want to *dynamically* load CGIs but statically
link the CGIs together with the mod_caml glue, is caml dynamic linking
still necessary for any *other* part of the mod_caml's design
(e.g. the interaction between mod_caml and Apache)?

Best,
-James

-------------------
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] mod_caml's bytecode restriction due to Apache or just CGI dyn'linking?

[James Leifer]

"Basile Starynkevitch [local]" <basile.starynkevitch@inria.fr> writes:

> Sorry for the shameless plug - but I think that ocamljit can be used
> to accelerate a bit such Ocaml propulsed web pages.

So, ocamljit plays well with dynamic .cmo linking?

-J

-------------------
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] mod_caml's bytecode restriction due to Apache or just CGI dyn'linking?

[Basile Starynkevitch [local]]

On Mon, Jun 21, 2004 at 09:33:23AM +0200, James Leifer wrote:
> "Basile Starynkevitch [local]" <basile.starynkevitch@inria.fr> writes:
> 
> > Sorry for the shameless plug - but I think that ocamljit can be used
> > to accelerate a bit such Ocaml propulsed web pages.
> 
> So, ocamljit plays well with dynamic .cmo linking?

Yes, it was designed to mimic as much as possible the bytecode interpreter.

The main misfeature of ocamljit is lack of [ocaml] debugger support -
because the few debug related bytecodes are not supported by it (in
the case yu run into them, you got a loud fatal error!)

-- 
Basile STARYNKEVITCH -- basile dot starynkevitch at inria dot fr
Project cristal.inria.fr - phone +33 1 3963 5197 - mobile 6 8501 2359
http://cristal.inria.fr/~starynke --- all opinions are only mine 

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