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