perl-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Philippe M. Chiasson" <>
Subject Re: Please help adding ModPerl::Interpreter
Date Sat, 13 Oct 2007 06:31:59 GMT
Torsten Foertsch wrote:
> On Wednesday 10 October 2007 21:20, Philippe M. Chiasson wrote:
>> The only question I have is wherever it's necessary to also expose the
>> following 2 items:
>> modperl_interp_pool_t * | IV
>> PerlInterpreter *       | IV
>> Especially in the current patch, what you get out will pretty much
>> be a useless blessed scalar you can't do anything with.
> Without these 2 lines no accessor methods would be created because the wrapxs 
> process obviously doesn't know how to convert it. In my first version I had 
> declared mip and perl as void* in 
> xs/tables/current/Apache2/ This way I also got these 
> members compiled in. But then I suspected that a source scan would never 
> generate that. Am I right?

Yes, absolutely correct!

> BTW, I forgot to mention, the patch creates a new map: 
> xs/maps/ Is that OK?

That's more than okay, that was the correct thing to do.

>> Apart that, looks great. At this point, I'd be happy to see it go in,
>> without documentation even, but at least with a minimal set of tests,
>> something like:
>> my $int = ModPerl::Interpreter->current;
>> ok($int);
>> is($int, 'ModPerl::Intereter');
>> ok($int->mip);
>> ok($int->refcnt);
>> [...]
>> To at least cover normal usage cases.
> Of course.

In the meantime, I've created a threading branch here:

And I've applied this change (rev 584377) as the first one in hopefully many more of
your patches. Only change is that I added minimal tests.

Note, this patch/test doesn't behave correctly with a non-threaded Apache.

> I need this module mainly for testing the interpreter management. The pair 
> ($$interp, $interp->num_requests) can be used as unique identifier for one 
> particular usage (the time between interp_select and interp_unselect) of that 
> interpreter.
> refcnt is used to check for example if creating pnotes would lock the interp.
> mip and perl are currently not used. They can be dropped if you think that 
> would be better

It's not much work to include them, so might as well keep them in.

> I am aware that if later on someone decides that a perl 
> interface to the mip structure would be good he has to change the API.

It's a change that would add to the existing API, so I wouldn't worry about
that case.

> But 
> that can be documented. On the other hand mip may be a useful tool to check 
> if a vhost with +Parent has really got a separate mip. But then an interface 
> to the mip->tipool might be useful to check how much interpreters are in use 
> at a certain point in time. Maybe I should provide a perl interface to that 
> too.

Maybe, yes. At some point I remember thinking that it would have simplified
things to just expose Perl interpreters to Perl, and do interpreter managment
in perl, but that's for another time ;-)

Philippe M. Chiasson     GPG: F9BFE0C2480E7680 1AE53631CB32A107 88C3A5A5       m/gozer\@(apache|cpan|ectoplasm)\.org/

View raw message