One of the main reasons I use mod_perl is because of the pre-fork caching
I can do in the parent that the children can share cheaply. I take huge
data structures and assemble them in ram as read-only databases (read
hash tables) that are much faster and simpler to access than sql (I use
sql only where my data is read/write).
With all this talk about threaded perl interpreters what I'd like to be
sure of is that in Apache 2.0 my model does not break. Can each private
perl interpreter keep its cached (shared) data structures in memory ?
Most of my mod_perl processes are big - 10-12 MB, but easily 90+ percent
of that is shared. I like this setup, and want to be sure that apache 2.0
does not break this in any way. threads ? are they really appropriate for
everyone ? can the old behavior be maintained ? If not, then we would seem
to be moving to a more php-like environment, which would be a major bust
for me. I can triple (sometimes more) the performance of my handlers by
packing my data that is read-only into memory, and using sql only as
needed !
Any comments ? Am I off base ? Worrying without cause ?
On Thu, 4 Nov 1999, Gerald Richter wrote:
> > I'm assuming that Perl itself is reentrant, since it has been embedded
> > in multithreaded environments before (IIS). Hopefully someone can
> > comment on that.
> >
> Perl 5.005 has experimetal thread support, Perl 5.006 might be stable
> enought to really use it.
>
> What ActiveState has done for IIS, is to pack the Perlinterpreter in a
> single C++ object (compile Perl with PERL_OBJECT) and now every request can
> get his own private Perlinterpreter. This model (maybe a pool of
> Perlinterpreters) may also work for mod_perl. Jochen Wiedman already has
> done some work on make mod_perl compile with a Perl that is build with
> PERL_OBJECT, but a lot of work is left...
>
> Gerald
>
> ---------------------------------------------------------------
> Gerald Richter ecos electronic communication services gmbh
> Internet - Infodatenbanken - Apache - Perl - mod_perl - Embperl
>
> E-Mail: [EMAIL PROTECTED] Tel: +49-6133/925151
> WWW: http://www.ecos.de Fax: +49-6133/925152
> ---------------------------------------------------------------
>
>
