Front page | perl.perl5.porters |
Postings from November 2003
On Sun, 16 Nov 2003 18:53:37 -0800, Stas Bekman <stas@stason.org> wrote:
>> 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.
As I said, I thought this was already the case almost all the time. I
just rechecked it and was surprised that both the Perl_safesysmalloc() and
friends as well as the PerlIO_* functions need dTHX.
I agree that they should have the *_nocontext versions for XS extensions
and that the PERL_CORE should always pass the context to them. If nothing
else, this should give us some speed gains. I'm very surprised that the
memory allocation function all use dTHX; I'll try to ask Sarathy tomorrow
why this is the case.
On a tangential note, I also noticed that perlio.c defines dSYS, which
seems to have the same purpose as dTHXs from perl.h (and is used in e.g.
util.c). They should probably be unified.
>> 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
I agree with all of this.
>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.
>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.
>> 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). 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.
Cheers,
-Jan
Thread Previous
|
Thread Next