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