Front page | perl.perl5.porters |
Postings from November 2003
On Tue, 18 Nov 2003 16:48:27 -0800, Stas Bekman <stas@stason.org> wrote:
>> I've been talking with Gisle about this recently to make dynamically
>> linked Perl more resilient against loading libperl.so from a different
>> architecture (e.g. threaded vs. non-threaded), but we haven't acted on
>> this discussion yet.
>
>It'd be nice if perl could provide this feature for all XS modules as well
>(via DynaLoader?) since this problem affects all Perl modules coming with
>shared libs.
I'll keep that in mind in case we actually try to do something about it.
[...]
>Thank you for pointing this out, Jan. Though I thought you were talking about
>old XS modules that don't use PERL_NO_GET_CONTEXT.
Yes, I am. And if you do a quick grep on CPAN, you'll see plenty of
modules that don't #define PERL_NO_GET_CONTEXT in their XS code, so this
is always relevant if the embedding application doesn't have *complete*
control over which modules are being used.
>Am I correct to say that if a given XS module uses PERL_NO_GET_CONTEXT define,
>all XSUBs will receive a real aTHX (my_perl/perl_interpreter) argument and not
>aTHX aliased to PERL_GET_CONTEXT.
They always _receive_ a real pTHX on entry. But when they call Perl APIs,
they don't pass this context, but fetch it from the TLS instead. This was
necessary because many modules use help functions that would need a dTHX
to get a my_perl definition:
void
my_helper(char *str) {
if (!str)
croak("Invalid argument to my_helper");
/* ... */
}
The croak() macro doesn't know if it is invoked from a function that has
defined a context (CODE/PPCODE) or a helper that doesn't. Therefore it
does the safe thing and always fetches the context from TLS.
The helper needs to be rewritten to either use dTHX or to pass in a pTHX_
if you want to use it under PERL_NO_GET_CONTEXT. If you just add a dTHX,
then you still rely on the context being set up correctly. When you add a
pTHX_, then all calls to the helper function must be modified too. Or you
need to add a Perl-like macro layer to hide this. :)
(I know this is a bad example because croak has the Perl_croak_nocontext()
version, but this is only true for APIs using variable length argument
lists).
[...]
>That means that applications embedding perl only need to call
>PERL_SET_CONTEXT() before calling Perl_eval_*(), which may use some old XS
>modules.
It is not just Perl_eval_*(). If you don't know which modules are being
used, then every Perl API must be protected by setting up the context:
Your API call may access an SV that has e.g. TIE magic attached to it that
is implemented by a module not using PERL_NO_GET_CONTEXT.
> If it's known that used XS modules don't need to access TLS then no
>context needs to be set before Perl_eval_*().
>
>If that's correct, than an embed perl app can completely get rid of
>PERL_SET_CONTEXT() calls.
That is true. However, I can't think of a scenario where you can
guarantee that all modules define PERL_NO_GET_CONTEXT. I certainly don't
see how this could ever be true for mod_perl.
Note that you must *also* check that the module doesn't use dTHX or any
other explicit use of PERL_GET_CONTEXT. PERL_NO_GET_CONTEXT only prevents
the implicit calls to PERL_GET_CONTEXT via aTHX.
Cheers,
-Jan
Thread Previous
|
Thread Next