From: skaller <skaller@users.sourceforge.net>
To: "Richard W.M. Jones" <rich@merjis.com>
Cc: caml-list <caml-list@inria.fr>
Subject: Re: [Caml-list] Native executable symtable
Date: 22 Nov 2004 14:25:04 +1100 [thread overview]
Message-ID: <1101093904.32394.162.camel@pelican.wigram> (raw)
In-Reply-To: <20041121233018.GB28429@annexia.org>
On Mon, 2004-11-22 at 10:30, Richard W.M. Jones wrote:
> On Mon, Nov 22, 2004 at 07:29:51AM +1100, skaller wrote:
> > 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).
>
> This isn't actually much of a problem with mod_caml. Deployments of
> Apache should limit the number of HTTP requests that a single Apache
> child can handle (MaxRequestsPerChild), after which the child exits.
> This parameter is commonly set low with mod_perl also, since Perl has
> several "issues" with running over long periods of time - it was
> designed for short command line scripts after all.
Ah, I see. So Apache is hacked to support broken module
implementations.. :)
There are other applicatins where this isn't possible,
for example Felix was originally designed for a telco
environment running say 20 CPU's, one thread per CPU,
but millions of 'micro' threads (one per phone call).
Restarting one thread in such an environment is possible but messy:
you either need to make the microthreads mobile so you can
move them from one CPU to another, or you have to be
willing to wait 20 minutes whilst some person who likes
long winded speeches (like me) finishes their call.
(Or just disconnect them .. :)
But basically you want to be able to run forever,
even upgrading the call handling logic whilst the
process is running. Total code use here isn't
the issue so much as dynamic upgrading -- the main
reason for unloading isn't to save memory, so much
as to be sure no one is using an old version
which happened to credit your account instead of
debiting it due to a bug .. :)
Anyhow to some extent I sympathise with the Ocaml team,
in that just saying 'dynamic loading of native code'
isn't a full answer. It promises something some programmer
not fully understanding it may try to use only to find
later that it isn't suitable because there are some hard
to understand compromises (eg insecure unloading, different
behaviour on different platforms, etc ..)
BTW: is mod_caml bytecode that much of a
performance issue for web service, compared
with Python,Php, Perl etc?
--
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
next prev parent reply other threads:[~2004-11-22 3:25 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
2004-11-21 20:39 ` malc
2004-11-21 23:30 ` Richard W.M. Jones
2004-11-22 3:25 ` skaller [this message]
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=1101093904.32394.162.camel@pelican.wigram \
--to=skaller@users.sourceforge.net \
--cc=caml-list@inria.fr \
--cc=rich@merjis.com \
/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