gozer at ectoplasm
Oct 12, 2007, 11:31 PM
Post #7 of 39
Torsten Foertsch wrote:
Re: Please help adding ModPerl::Interpreter
[In reply to]
> 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/StructureTable.pm. 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/modperl_structures.map. 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;
>> is($int, 'ModPerl::Intereter');
>> 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
> 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 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
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