develooper Front page | perl.perl5.porters | Postings from November 2003

Re: need your help to do some (simple?) patching

Thread Previous | Thread Next
Stas Bekman
November 18, 2003 09:28
Re: need your help to do some (simple?) patching
Message ID:
Jan Dubois wrote:
> On Mon, 17 Nov 2003 10:34:54 -0800, Stas Bekman <> 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:
> 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  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.


can 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 Of course this behavior is really needed for developers 
who have a bunch of 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
>>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     mod_perl Guide --->

Thread Previous | Thread Next Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at | Group listing | About