develooper Front page | perl.perl5.porters | Postings from November 2003

Re: need your help to do some (simple?) patching

Thread Previous | Thread Next
Jan Dubois
November 18, 2003 15:52
Re: need your help to do some (simple?) patching
Message ID:
On Tue, 18 Nov 2003 09:18:34 -0800, Stas Bekman <> wrote:

>can 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 Of course this behavior is really needed for developers 
>who have a bunch of 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 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

>> 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

Are we talking about the same thing?

Thread Previous | Thread Next Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at | Group listing | About