----- Original Message -----
From: "Doug MacEachern" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: 21 April 2000 06:51
Subject: mod_perl-1.99_01-dev
> eric and stas already let the cat out of the bag, but i was planning to
> give a summary of what's in progress for mod_perl-2.0 anyhow :)
> i've included a summary of the pieces i'm currently working on, there's a
> great deal left to do, but it's looking good and moving along fast.
> i'll be putting these design notes into cvs soon, along with a
> bigger-picture plan, which should make it easy to see where folks can help
> out if you're interested...
This is excellent news - I was going to ask what the status of
mod_perl.pre-2.X !
> interpreter pool
> ----------------
>
> this logic is only enabled if Perl is built with -Dusethreads
> otherwise, mod_perl will behave just as 1.xx, using a single
> interpreter, which is only useful if you're using the prefork mpm.
<bits snipped>
This may be a question born of ignorance / inexperience but here goes:
Does this mean that we {will|may} be able to use the interpreter pool to
set up X Perl interpreters (say 20 to service dynamic handlers) with Z
apache (say 60 to handle static + dynamic content - assuming the dynamic
content is passed to the Perl interpreters) children, and hence have
significant memory savings as we can avoid (in some cases) the light / heavy
httpd model ?
Or have I missed the plot vis-a-vi apache 2.0 and threads ?
>
> i'm also interested in shane's "garbage collector", which could also
> run in it's own thread, examining the padlists of idle interpreters
> and deciding to release and/or report large strings, array/hash sizes,
> etc., that Perl is keeping around as an optimization.
Adding in the garbage collector would also be a massive bonus if people do
allot of sorting / data manipulation / sort term caching in RAM (Perl).
<other bits snipped>
Again thanks for the good news.
Greg Cope
