Torsten Foertsch schrieb:
On Sun 18 Jan 2009, Michael Ludwig wrote:
Hmm. Not sure what to make of this threaded Perl.
In fact, it is worse than fork()ing off unix processes because the
interpreter data is completely copied while a new interpreter is
created. On the other hand a forked process copies only those pages
that are written to.
Thanks. If I'm understanding correctly and this is true (and not
considering SEGVs), the total memory cost for a mod_perl on a worker
MPM should outweigh that for mod_perl on a prefork MPM, which seems
to not be aligned with what Craig has observed.
I haven't used Sleepycat::DbXml but I use BerkeleyDB in production
with prefork, see Apache2::Translation on CPAN.
Looks interesting. I'm going to take a look.
What I have learned is, you can't open the BDB env in the parent
apache. When I wrote that piece I also had problems when I opened the
env in the parent and then closed it before forking children. Perhaps
they are gone in a newer version.
I think with prefork opening the env in a ChildInit handler should
work. I ended up with the connect-at-first-usage approach
unless( $connected ) {
connect();
$connected=1;
}
because I test almost all my modules also with a threaded MPM and the
ChildInit hook is run once per process not once per Perl interpreter.
In order to be on the safe side as far as Berkeley DB is concerned,
you'd have to make sure up front that the environment is safe to use,
which is done by running recovery (DB_RECOVER flag, DB_RUNRECOVERY error
code) in a single thread or process that has exclusive access to the
environment.
Given that we're experiencing problems (SEGVs) when trying to open
the environment up front in the parent process, it looks like this
requirement is not easy to meet on the Apache/mod_perl platform.
Michael Ludwig
