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

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

Thread Previous | Thread Next
From:
Stas Bekman
Date:
November 17, 2003 10:45
Subject:
Re: need your help to do some (simple?) patching
Message ID:
3FB914CE.6000505@stason.org

>>calls, XS modules and embedded applications which can pass the context 
>>explicitly no longer have to call PERL_SET_CONTEXT at all! You get better 
> 
> 
> XS modules already don't have to call PERL_SET_CONTEXT at all if you write
> them correctly (using PERL_NO_GET_CONTEXT, passing the context explicitly
> to pure C functions).  Maybe this information should be published more
> prominently so that new modules take advantage of that.
> 
> I'm not sure what "embedded" applications are.  If you are talking about
> "embedding" applications (those who embed Perl interpreters vs. the other
> way round), then they will still have to juggle with PERL_SET_CONTEXT
> unless they can guarantee that the Perl code isn't using any modules,
> which seems unrealistic to me.

Not really, they shouldn't if they create/clone the interpreters themselves. 
like mod_perl 2.0 does. Look at this scary example:

http://www.perldoc.com/perl5.8.0/pod/perlembed.html#Maintaining-multiple-interpreter-instances

      PERL_SET_CONTEXT(one_perl);
      perl_construct(one_perl);
      PERL_SET_CONTEXT(two_perl);
      perl_construct(two_perl);

      PERL_SET_CONTEXT(one_perl);
      perl_parse(one_perl, NULL, 3, one_args, (char **)NULL);
      PERL_SET_CONTEXT(two_perl);
      perl_parse(two_perl, NULL, 3, two_args, (char **)NULL);

      PERL_SET_CONTEXT(one_perl);
      perl_run(one_perl);
      PERL_SET_CONTEXT(two_perl);
      perl_run(two_perl);

      PERL_SET_CONTEXT(one_perl);
      perl_destruct(one_perl);
      PERL_SET_CONTEXT(two_perl);
      perl_destruct(two_perl);

      PERL_SET_CONTEXT(one_perl);
      perl_free(one_perl);
      PERL_SET_CONTEXT(two_perl);
      perl_free(two_perl);

This is just plain broken, because you already explicitly pass the context around.

And this code in the example doesn't even do anything. Now think mod_perl 2.0 
threaded mpm, which jungles interpreters all the time. You get the idea...

>>performance and you avoid the potential problems when you allocate/destroy 
>>things from the wrong perl context (see the recent bug in threads.xs which 
>>won't have a chance to exist if perl didn't have this internal problem).
> 
> 
> I assume you are talking about the bug in threads::shared.  I don't see
> how that bug would have been prevented.  The thread::shared module is
> special in that it is dealing with memory sharing between interpreters, so
> it would still need 2 different context variables internally.  However,
> both SvPV() and hv_exist() implicitly use the aTHX context.  So
> threads::shared would still have needed the
> 
>     aTHX = PL_sharedsv_space;
> 
> assignment at the right place for both SvPV() and hv_exist() to expand
> correctly.  So I don't see how this bug would have been prevented.

You are correct. I should have known better.

>>>So unless you break source code compatibility with older XS modules, there
>>>is no way you can get rid of doing the set/restore context dance whenever
>>>you need to call into Perl from an embedding environment.
>>
>>I don't think that my suggestion breaks backwards source compatibility. Do I 
>>miss something? It's about extending API not replacing it.
> 
> 
> I think you are right that we should be able to realize possible
> performance gains without breaking compatibility.
> 
> But I don't understand why you believe that you can get away with not
> calling PERL_SET_CONTEXT in embedding applications: in XS modules, aTHX is
> redefined to be PERL_GET_THX unless you #define PERL_NO_GET_CONTEXT (in
> XSUB.h). 

embedded applications and XS modules are usually two totaly different beasts 
with regards to context managements. In embedded applications you control the 
creating/cloning of the interepreter and you can always pass it around. In XS 
modules you rely on the perl giving it to you via XS(foo) wrappers.

 > If you call XS code from the wrong context, it is very likely to
 > create problems.  I don't see a source code compatible solution to this.

That's true.

__________________________________________________________________
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.com


Thread Previous | Thread Next


nntp.perl.org: Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at ask@perl.org | Group listing | About