Stas Bekman wrote:
There are a few issues left, which are hopefully will be resolved shortly.
I have one big issue with porting my code to mp2 which I'm not sure if there's a resolution to?
I'm currently running mp1 on Win32. The Perl interpreter used by mp1 on Win32 is single-threaded, which causes a bottleneck for busy sites because the Apache child threads serving responses have to fight over access to the single Perl thread available. However, we've found that it works perfectly well in practice on small intranet sites, and this is what we're using it for.
If I switch to mp2 then the Perl interpreter is now multi-threaded, thus removing the performance bottleneck, which should be great except for one thing: All our mp code involves DBI (& DBD-mysql), but DBI is not thread-safe!
I have a trivial DBI program (not involving mp at all) which crashes on Win32 with the delightful "free to wrong pool" error:
use DBI; use threads; my $dsn = 'dbi:mysql:test'; my $usr = 'root'; my $pwd = undef; my $t = threads->new(\&dbsub); $t->join(); sub dbsub { my $dbh = DBI->connect($dsn, $usr, $pwd); $dbh->disconnect(); }
When I posted this to the DBI users mailing list looking for a resolution, Tim Bunce's response was simply "Don't use threads". (http://www.mail-archive.com/[email protected]/msg22595.html)
So my expectation would certainly be that if I port my mp1 stuff to mp2 then it'll all break. Horribly.
Is there a way to configure mp2 to build with a non-threaded Perl, or at least to run it in such a way as to not make use of the Perl interpreter's threads, in order to simulate mp1-style behaviour?
Unfortunately not, since Apache on win32 doesn't run in a single thread environment.
However, you could try a very simple solution - make each perl interpreter pool of 1 interpreter size and voil� you should have the same thing you had with mp1. If that works, you could create different pools in different vhosts (with +Parent) and then you will have more than one interpreter for unrelated vhosts. I haven't tested that but it might work.
I realise that re-introducing the performance bottleneck is not ideal, but at least I can live with it.
(The other obvious solution of porting from Win32 to a decent OS is sadly not an option before anyone suggests it.)
Doh! I was just about to suggest it :(
I'll ask Tim what involves in making DBI thread-safe and if it's doable and not too complicated, I may try to do that after 2.0 is released. This is certainly going to be a problem for people wanting to run the worker mpm on Unix, though they have an alternative of prefork mpm, which unfortunately you don't.
-- __________________________________________________________________ Stas Bekman JAm_pH ------> Just Another mod_perl Hacker http://stason.org/ mod_perl Guide ---> http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
