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

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

Thread Previous | Thread Next
From:
Jan Dubois
Date:
November 17, 2003 15:59
Subject:
Re: need your help to do some (simple?) patching
Message ID:
l2nirvck6s0nul6k6tg6v32fvik0dekgdu@4ax.com
On Mon, 17 Nov 2003 10:34:54 -0800, Stas Bekman <stas@stason.org> wrote:

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

Yes, but that is a pretty unrealistic example.  Normally you would run
alloc, construct and parse all one after another, so you don't need the
repeated PERL_SET_CONTEXT calls.

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

But I agree that all these calls could do the save/restore context calls
themselves, hiding it from the embedding application.

The fun really starts after you have called perl_run() on a couple of
interpreters and then call back into them from event loops or other
callbacks.  Should Perl_call_pv() etc. also implicitly set and restore the
context?  Where do you draw the line?

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

Oh, I'm used to cases where multiple interpreters in the same process
space exist, and they don't know about each other because they are created
by different dynamically loaded libraries.  The real fun starts if they
pull in multiple (different) copies of libperl.so/perl5x.dll.  Actually,
it falls apart at that time, but it takes quite a while to discover what
is going on...  So I'm very aware of the pains you are going through.

[...]

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

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.

Cheers,
-Jan


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