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/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; >> 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: http://svn.apache.org/repos/asf/perl/modperl/branches/threading 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 http://gozer.ectoplasm.org/ m/gozer\@(apache|cpan|ectoplasm)\.org/
signature.asc
Description: OpenPGP digital signature
