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 17, 2003 10:45
Re: need your help to do some (simple?) patching
Message ID:

>>calls, XS modules and embedded applications which can pass the context 
>>explicitly no longer have to call PERL_SET_CONTEXT at all! You get better 
> XS modules already don't have to call PERL_SET_CONTEXT at all if you write
> them correctly (using PERL_NO_GET_CONTEXT, passing the context explicitly
> to pure C functions).  Maybe this information should be published more
> prominently so that new modules take advantage of that.
> 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:


      perl_parse(one_perl, NULL, 3, one_args, (char **)NULL);
      perl_parse(two_perl, NULL, 3, two_args, (char **)NULL);




This is just plain broken, because you already explicitly pass the context around.

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...

>>performance and you avoid the potential problems when you allocate/destroy 
>>things from the wrong perl context (see the recent bug in threads.xs which 
>>won't have a chance to exist if perl didn't have this internal problem).
> I assume you are talking about the bug in threads::shared.  I don't see
> how that bug would have been prevented.  The thread::shared module is
> special in that it is dealing with memory sharing between interpreters, so
> it would still need 2 different context variables internally.  However,
> both SvPV() and hv_exist() implicitly use the aTHX context.  So
> threads::shared would still have needed the
>     aTHX = PL_sharedsv_space;
> assignment at the right place for both SvPV() and hv_exist() to expand
> correctly.  So I don't see how this bug would have been prevented.

You are correct. I should have known better.

>>>So unless you break source code compatibility with older XS modules, there
>>>is no way you can get rid of doing the set/restore context dance whenever
>>>you need to call into Perl from an embedding environment.
>>I don't think that my suggestion breaks backwards source compatibility. Do I 
>>miss something? It's about extending API not replacing it.
> 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.

 > If you call XS code from the wrong context, it is very likely to
 > create problems.  I don't see a source code compatible solution to this.

That's true.

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