Front page | perl.perl5.porters |
Postings from November 2003
Jan Dubois wrote: > On Tue, 18 Nov 2003 09:18:34 -0800, Stas Bekman <stas@stason.org> wrote: > > >>can libperl.so include some watermark and the application loading it verify >>that it's a correct one? So it'd fail to load unless it was compiled against >>that exact libperl.so. Of course this behavior is really needed for developers >>who have a bunch of libperl.so libs and will be enabled only on demand? > > > 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. > This doesn't catch the other error that I've observed twice now: that 2 > identical copies of perl56.dll were mapped into the same process, one via > normal OS level dynamic linking, and the other via explicit LoadLibrary() > (dlopen() on Unix) with a full path. The different copies will use > different TLS slots to store the context. One example where this can > happen is when you use ActiveX controls implemented in Perl from another > application that embeds Perl (e.g. IIS). I've put code checking for this > in the ActiveState products that are likely to be involved in these > scenarios, but I don't know if there is something you can do about this in > general. That's a tough one. It's probably an OS problem if it allows you to do that (i.e. it should have checked whether it has already loaded that library before (e.g. by marking internally the full path to the loaded library)) >>>That was my exactly point. For new XS modules, the problem is already >>>solved, as long as the module author knows how to deal with it. For >>>applications it cannot be solved as long as you require source code >>>compatibility with old style modules. >> >>Sorry, I lost you here, Jan. Why do you talk about "old style modules" in >>applications. I'm talking about embedded perl applications, not 3rd party >>modules, which I believe will work all the same. > > > I'm under the impression that you believe that the embedding application > will not need to call PERL_SET_CONTEXT() if all places in the core pass > aTHX explicitly. I'm trying to explain why this is not true: > > When you call XS code, it uses PERL_GET_THX to retrieve the context from > TLS and pass this on to any Perl APIs it is calling. So if you are not > setting the context before calling into Perl, then Perl cannot call into > XS code. XS code does *not* use the passed in context. aTHX is remapped > to PERL_GET_THX. > > Are we talking about the same thing? 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. 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. At least that's how I read this snippet from XSUB.h: #if defined(PERL_IMPLICIT_CONTEXT) && !defined(PERL_NO_GET_CONTEXT) && !defined(PERL_CORE) # undef aTHX # undef aTHX_ # define aTHX PERL_GET_THX # define aTHX_ aTHX, #endif ... #define XS(name) void name(pTHX_ CV* cv) That means that applications embedding perl only need to call PERL_SET_CONTEXT() before calling Perl_eval_*(), which may use some old XS modules. 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. __________________________________________________________________ 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