Stas Bekman <[EMAIL PROTECTED]> writes:
Joe Schaefer wrote:
[...]
mod_perl is trying to deparse the anonymous sub, and it needs B::Deparse for that. (I'm still trying to grok the necessity/safety of the deparse.)
Right, that makes more sense. The necessity is explained in modperl_handler.c, and pasted here for your convenience (and comments):
#ifdef USE_ITHREADS /* XXX: perhaps we can optimize this further. At the moment when * perl w/ ithreads is used, we always deparse the anon subs * before storing them and then eval them each time they are * used. This is because we don't know whether the same perl that * compiled the anonymous sub is used to run it.
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Can you explain under what circumstance it actually happens, or even matters? AFAICT the sub is compiled into an optree as soon as the module is loaded. Here are the two cases I'm struggling to understand:
1) If the module loads before the interpreter are cloned, won't the cloning operation allow the anon sub to run safely in any interpreter?
2) If it isn't loaded before cloning, than doesn't each individual interpreter load the module before running the code? If so, how could the issue present itself in this case?
Very simple: modperl can't store those CVs, since it can store only one CV per handler, but there are many interpreters and each one of the them will have a different CV of the same compiled anon sub.
There are several cases we need to deal with.
1) compile time definition in the perl module
$r->push_handlers(PerlTransHandler => sub { .... });2) run time definition
$r->push_handlers(PerlTransHandler => eval 'sub { .... }');there is no way this can be precompiled before the run time.
3) .conf inlined handlers:
#httpd.conf:
PerlTransHandler 'sub { ... }'Here the handler is not compiled until the run-time
Now, let's say we could somehow store those CVs in each interpreter, rather than mod_perl's handlers (which I can't see how is it possible w/o turning anon subs into named, which may have some bad side-effects. We still have problems:
if we have:
PerlInterpScope handler
http://perl.apache.org/docs/2.0/user/config/config.html#C_PerlInterpScope_
it's possible that the module was compiled during PerlTranshandler, by interpreter A, but interpreter B was selected to run PerlResponseHandler (which is the anon sub). What do we do now? B has no idea what that anon-sub is, as it didn't compile it.
At the moment the solution of B::Deparse "works" since mod_perl needs to store only one source per anon sub and each interpreter compiles it before running it.
-- __________________________________________________________________ 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]
