Front page | perl.perl5.porters |
Postings from November 2003
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. >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? >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. [...] >> 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. Cheers, -JanThread Previous | Thread Next