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.
[...]
> > Is it really ok for interpreter B to deparse A's sub here?
>
> It doesn't do that. A deparses the function and stores its source in
> the mod_perl struct. Then B compiles it before running it.
Thanks for clearing that up for me!
--
Joe Schaefer
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
