On Sat, 6 May 2000, Greg Cope wrote:
> : > > But you will be not able to tune the two types of the threads to have
> : > > different Apache parameters (MaxRequests and others) so I'm not sure
> you
> : > > will get rid of the dual setup, unless these will be taken care of by
> : > > mod_perl.
> : >
> : >well, there is a PerlInterpMaxRequests parameter in 1.99_01-dev, which
> : >knocks off the Perl clone after x number of requests. in addition, the
> : >pool of interpreters are pulled and putback from the head of the list, so
> : >you are getting re-used allocations (e.g. padlists aka lexicals). that
> : >is, say you configured PerlInterpStart to 10, but average no more than 5
> : >concurrent requests. you have 5 clones with allocated padlists, and 5
> : >which are much smaller (but ready for conncurrent requests > 5). this is
> : >unlike 1.3 where you have 10 children, chances are high each of them will
> : >endup will allocated padlists, as there's no control over which child
> : >handles a request.
> : >
> : >i'm not saying 2.0 will rid the need for a dual setup, but the Perl side
> : >is looking a whole lot smaller (er, less fat) at this point.
>
> If using the threaded model can we not configure say:
>
> 10 apache children (fixed)
> X number of threads
> Y PerlInterpStart
yes.
> This would (if my understanding is correct) result in a request arriving and
> being :
>
> - either be dealt with by a normal apache thread if not a mod_perl
> handler - i.e {html|gif|png|jpeg}
> - or a by a light apache thread that calls a perlInterpreter from the pool
> to handle the mod_perl handler....
there's no 'normal apache thread' or 'light apache thread', just 'apache
thread'. all requests are handled the sameway thread-wise. the only
difference for Perl requests is that an interpreter is plucked from the
pool and callbacks into that Perl runtime are made.
> Combine with a garbage collector thread this would be excellent as it would
> seriously reduce memory consumption (one of mod_perl's present weaknesses)
indeed.
