Stas Bekman <[EMAIL PROTECTED]> writes:
Joe Schaefer wrote:
[...]
I'm still of the opinion that the best way to resolve this problem is to ensure the same interpreter always runs whatever extra hooks it creates (eg pool cleanups, filters/handlers added, etc.).
That will be only possible if you drop the pools functionality, the interpreter scopes, etc.
Obviously I don't see why that is so. In fact, I see that it is already implemented in parts of mod_perl, for instance when registering a
pool-cleanup callback:
$sp->cleanup_register(sub { print @{ $_[0] || [] } }, [1..3]);
Here the currently active interpreter has its refcount incremented by
mpxs_apr_pool_cleanup_register(). AFAICT the interpreter is not allowed to reenter the thread pool until this cleanup has run. I don't see how PerlInterpScope influences this behavior at all.
I still believe that this is the right approach, and again I wonder why this cannot also be used in the situations you cited earlier in this thread.
Anti-Example 1: parent interpreter compiles the anon-sub, which interpreter are you going to stick to that anon-sub?
Anti-Example 2: PerlPreConnectionHandler compiles the anon-sub, that sub is to run in PerlResponseHandler. If the interpreter scope is set to 'handler' (and if there is a different pool for each phase), the interpreter that has run PerlPreConnectionHandler can't possible come even close around PerlResponseHandler.
In any case, this is not feasible, the way things are initialized now, since anon-subs aren't accessible from perl once you've compiled them (i.e. if you didn't store it somewhere, you can't find it anymore). And you can't store them in mod_perl, since it can store only one entry per registered handler - it can't store N entries.
Just try to take each of the 3 cases I've explained earlier and see how can you compile and where can you store it (even if you could stick the perl interpreter to it).
regarding the example of pool cleanup, I believe that it's broken in the case of interpreter scope functionality utilization.
As mentioned before hardly any of these interpreter scope/pool features are exercised, so...
-- __________________________________________________________________ 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]
