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 16, 2003 19:03
Re: need your help to do some (simple?) patching
Message ID:
Jan Dubois wrote:
> On Sat, 15 Nov 2003 16:16:53 -0800, Jan Dubois <>
> wrote:
>>>In an attempt to be the monkey, I did what seemed correct.  All tests
>>>passed, did I do something right (assuming the latter)?  If not, I
>>>could use some more clues.  Thanks.
>>No, you should *not* change any of the *_nocontext() functions.  They are
>>only there for source code compatibility of older extensions.  They all
>>already have a corresponding version without the "_nocontext" suffix.  The
>>core code should *only* call the latter.
>>A simple way to make sure that the core doesn't call any of the
>>*_nocontext() functions would be to just delete all of them and see if
>>Perl still builds and compiles.
> Actually, ignore the paragraph above.  I'm pretty sure that Perl core
> won't call these functions, given how the macros are defined.  All this is
> only relevant if you are using PERL_IMPLICIT_CONTEXT (which is implied by
> After thinking some more about Stas' request, I fail to see how any of
> this would help.  You would not only have to make all of core Perl pass
> the context (which it already does 98% of the time), but you would also
> have to modify all modules out there as well (CPAN and otherwise).

I guess I wasn't clear. I didn't suggest to remove the old APIs. I suggested 
to add new APIs which now accept pTHX_ as the first argument, and consequently 
adjust the perl-core (only!) to use those functions. Any XS modules will still 
be able to use the old API without passing an explicit context.

> Whenever you call into Perl for anything non-trivial, there is a chance
> that Perl may call code from an XS extension (e.g. by evaluating magic
> attached to an SV).  And if that extension hasn't been rewritten using the
> PERL_NO_GET_CONTEXT define, the extension code may still fetch the context
> from TLS.

There is a chance, yes. But why should code that passes an explicit context 
suffer because of other XS modules. PERL_SET_CONTEXT is expensive. It becomes 
even more expensive when you have to call it many times, when you have to 
manipulate interpreters. If perl core is cleared of dTHX in its internal 
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 
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).

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

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