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

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

Thread Previous | Thread Next
Stas Bekman
November 18, 2003 17:26
Re: need your help to do some (simple?) patching
Message ID:
Jan Dubois wrote:
> 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.

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

#if defined(PERL_IMPLICIT_CONTEXT) && !defined(PERL_NO_GET_CONTEXT) && 
#  undef aTHX
#  undef aTHX_
#  define aTHX          PERL_GET_THX
#  define aTHX_         aTHX,
#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 

Stas Bekman            JAm_pH ------> Just Another mod_perl Hacker     mod_perl Guide --->

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