Stas Bekman <[EMAIL PROTECTED]> writes: > Joe Schaefer wrote:
> >>#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. [...] > 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 Thanks Stas for the clear explanation. Although I don't fully understand how the interpreter pools operate yet, 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.). > 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. Is it really ok for interpreter B to deparse A's sub here? -- Joe Schaefer --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]