Stas Bekman <[EMAIL PROTECTED]> writes:
Joe Schaefer wrote:
Stas Bekman <[EMAIL PROTECTED]> writes:
[...]
Anti-Example 1: parent interpreter compiles the anon-sub, which interpreter are you going to stick to that anon-sub?
A: As I stated, I expect the intepreter which invokes cleanup_register() to also be the one which executes the anonymous sub during $sp's pool cleanup. Are you saying that doesn't work if the interpreter is actually a clone, and not the parent?
I think what happens is this:
If the (very top) parent perl interpreter is attached to the cleanup hook (which only makes sense for cleanup callbacks registered at the server startup), there is no problem, since when those callbacks are called, there are no more threads and all the calls will be serialized and that interpreter will never be used at the same time by two threads (since there are no threads on shutdown).
but you can't stick that very top parent perl interpreter to an anon-sub,
because it's not thread safe.
Agreed, in the abstract. So on to the next question- when does the parent interpreter have to deal with such anon-subs? Certainly during server config, when it encounters things like
PerlResponseHandler 'sub { print "foo\n"; return OK }'
Nope. it doesn't compile them at the server startup, it just stores the source code in the modperl struct. B::Deparse has nothing to do with this case. B::Deparse is only used with the case of the perl code pushing an anon-sub:
$r->push_handlers(PerlTransHandler => sub { .... });Anywhere else besides the Perl*Handlers? Do the <Perl> sections
a similar problem? If not, then a simple way to address this would be to have the parent interpreter not compile such strings, which
might avoid the deparse overhead.
You mean:
<Perl>
$s->push_handlers(PerlPreConnectionHandler => sub { .... });
</Perl>that's exactly the same as having it in the plain perl module, with the only difference that the <Perl> sections are always executed right away, whereas a plain perl module will get compiled right away when PerlModule is encountered, only if perl interpreter was started early, i.e. if a <Perl> section or PerlLoadModule was encountered before.
If you did, several threads may try to use the same interpreter at the same time at run time. Moreover you aren't even allowed to use that very top parent interpreter, nowhere but at the startup and shutdown.
I hope that answers the question. I'm not sure why you are asking about the clone, when there is already a problem with the top-level perl, in the simplest case where there are no clones.
I thought there was always at least one clone, and that the parent interpreter was reserved for just doing startup/shutdown/cloning:
http://perl.apache.org/docs/2.0/user/design/design.html#Interpreter_Management
When the server is started, a Perl interpreter is constructed, compiling any code specified in the configuration, just as 1.0
does. This interpreter is referred to as the "parent"
interpreter. Then, for the number of PerlInterpStart configured, a
(thread-safe) clone of the parent interpreter is made (via
perl_clone()) and added to the pool of interpreters. This clone copies
any writeable data (e.g. the symbol table) and shares the compiled
syntax tree.
That's correct (in the case of threaded mpm), but again the problem exists before the first clone is done, since it's quite possible that the parent interpreter is the one that compiles the perl code with anon sub, in which case you can't attach the parent perl interpreter to that compiled code.
-- __________________________________________________________________ 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]
