Author: stas Date: Tue Nov 30 10:35:04 2004 New Revision: 109224
URL: http://svn.apache.org/viewcvs?view=rev&rev=109224 Log: init the MP_global_anon_cnt only once in the parent server
Modified: perl/modperl/trunk/src/modules/perl/mod_perl.c
Modified: perl/modperl/trunk/src/modules/perl/mod_perl.c
Url: http://svn.apache.org/viewcvs/perl/modperl/trunk/src/modules/perl/mod_perl.c?view=diff&rev=109224&p1=perl/modperl/trunk/src/modules/perl/mod_perl.c&r1=109223&p2=perl/modperl/trunk/src/modules/perl/mod_perl.c&r2=109224
==============================================================================
--- perl/modperl/trunk/src/modules/perl/mod_perl.c (original)
+++ perl/modperl/trunk/src/modules/perl/mod_perl.c Tue Nov 30 10:35:04 2004
@@ -279,9 +279,11 @@
av_push(GvAV(PL_incgv),
newSVpv(ap_server_root_relative(p, "lib/perl"), 0));
#endif /* MP_COMPAT_1X */
- - modperl_handler_anon_init(aTHX_ p);
- +
+ if (!s->is_virtual) {
+ modperl_handler_anon_init(aTHX_ p);
+ }
+
So thanks to Ian's setup we have uncovered this bug, but it's not the end. Now the new problem (yet untested) is that if a vhost with its own interpreter pool runs an anon-handlers it'll try to use the parent's perl context to do the mutex locking, which might have its own thread-safety issues. We need to look at the source of those lock functions to be sure. And if everything else fails fallback to use apr mutex locking.
-- __________________________________________________________________ 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]
