Front page | perl.perl5.porters |
Postings from November 2003
Jan Dubois wrote: > On Sat, 15 Nov 2003 16:16:53 -0800, Jan Dubois <jand@ActiveState.com> > 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 > MULTIPLICITY and USE_ITHREADS). > > 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 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