Front page | perl.perl5.porters |
Postings from November 2003
Jan Dubois wrote: > On Mon, 17 Nov 2003 10:34:54 -0800, Stas Bekman <stas@stason.org> wrote: > > >>>I'm not sure what "embedded" applications are. If you are talking about >>>"embedding" applications (those who embed Perl interpreters vs. the other >>>way round), then they will still have to juggle with PERL_SET_CONTEXT >>>unless they can guarantee that the Perl code isn't using any modules, >>>which seems unrealistic to me. >> >>Not really, they shouldn't if they create/clone the interpreters themselves. >>like mod_perl 2.0 does. Look at this scary example: >> >>http://www.perldoc.com/perl5.8.0/pod/perlembed.html#Maintaining-multiple-interpreter-instances > > > Yes, but that is a pretty unrealistic example. Normally you would run > alloc, construct and parse all one after another, so you don't need the > repeated PERL_SET_CONTEXT calls. Agreed, but it just demonstrates that if you switch interpreters a lot you need to call lots of PERL_SET_CONTEXT calls. >>This is just plain broken, because you already explicitly pass the context around. > > > But I agree that all these calls could do the save/restore context calls > themselves, hiding it from the embedding application. > > The fun really starts after you have called perl_run() on a couple of > interpreters and then call back into them from event loops or other > callbacks. Should Perl_call_pv() etc. also implicitly set and restore the > context? Where do you draw the line? Ah, no, I didn't suggest to move PERL_SET_CONTEXT calls inside the functions that already receive pTHX_. That'd be very inefficient. So there is no need for a line to be drawned. >>And this code in the example doesn't even do anything. Now think mod_perl 2.0 >>threaded mpm, which jungles interpreters all the time. You get the idea... > > > Oh, I'm used to cases where multiple interpreters in the same process > space exist, and they don't know about each other because they are created > by different dynamically loaded libraries. The real fun starts if they > pull in multiple (different) copies of libperl.so/perl5x.dll. Actually, > it falls apart at that time, but it takes quite a while to discover what > is going on... So I'm very aware of the pains you are going through. ouch. can libperl.so include some watermark and the application loading it verify that it's a correct one? So it'd fail to load unless it was compiled against that exact libperl.so. Of course this behavior is really needed for developers who have a bunch of libperl.so libs and will be enabled only on demand? >>>I think you are right that we should be able to realize possible >>>performance gains without breaking compatibility. >>> >>>But I don't understand why you believe that you can get away with not >>>calling PERL_SET_CONTEXT in embedding applications: in XS modules, aTHX is >>>redefined to be PERL_GET_THX unless you #define PERL_NO_GET_CONTEXT (in >>>XSUB.h). >> >>embedded applications and XS modules are usually two totaly different beasts >>with regards to context managements. In embedded applications you control the >>creating/cloning of the interepreter and you can always pass it around. In XS >>modules you rely on the perl giving it to you via XS(foo) wrappers. > > > That was my exactly point. For new XS modules, the problem is already > solved, as long as the module author knows how to deal with it. For > applications it cannot be solved as long as you require source code > compatibility with old style modules. Sorry, I lost you here, Jan. Why do you talk about "old style modules" in applications. I'm talking about embedded perl applications, not 3rd party modules, which I believe will work all the same. __________________________________________________________________ Stas Bekman JAm_pH ------> Just Another mod_perl Hacker http://stason.org/ mod_perl Guide ---> http://perl.apache.org mailto:stas@stason.org http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.comThread Previous | Thread Next