Stas Bekman <[EMAIL PROTECTED]> writes:
> Joe Schaefer wrote:
[...]
> > 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 { .... });
OK- thanks for the correction and clarification!
> > 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>
>
Yup, exactly!
This difference (merely compiling code vs. actually executing the code)
*does* make a difference in what I'm proposing, since I want the
interpreter which *executes* push_handlers() (& its relatives) to stick
around and execute the /callback also. Obviously that proposal doesn't
quite work when the parent interpreter is the one which executes the
code, so I will eventually need to amend my proposal so it deals with
that. But lets leave that issue unresolved for the moment...
> 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.
[...]
> 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.
I'm still confused by this line of reasoning, because it seems
you're not distinguishing between compile time vs runtime, but
the problem might just be a difference in terminology. Perhaps
this will help- suppose
"C" = perl code which contains an anon sub "S", e.g. using the above
$s->push_handlers(PerlPreConnectionHandler => sub { .... });
(C represents the whole line, and S is just the anon sub).
Please clarify/comment/correct the following:
If interpreter I compiles C, but does not execute it,
and then I clones J, J will not have any problem executing C.
However, it is desirable that J should also be the interpreter
which executes S - the anon sub which was created by J's execution
of C. Because if we guarantee that only J will execute S, we
avoid the (slow, and occasionally unreliable) deparse/reparse cycle
that a different interpreter would require. If we cannot make
that guarantee, J must deparse S when it executes C (and observing
that I actually compiled both C and S).
--
Joe Schaefer
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
