Did you see my comment about removing the subpool part from t/t/response/TestAPR/pool.pm "fixing" it?
(http://marc.theaimsgroup.com/?l=apache-modperl-dev&m=106424373602910&w=2)
Basically, this broke:
my $p = APR::Pool->new; my $subp = $p->new; $p->destroy;
but this worked:
my $p = APR::Pool->new; $p->destroy;
Dunno if there's anything in that.
I'm really sorry I hadn't been following this thread more closely - I caught the start and figured it was a Win32 thing that I couldn't help with...
at any rate, I noticed a few interesting things when I was implementing DESTROY, namely that get_parent() and is_ancestor() did not report back as expected. that is,
ok($p == $subp->get_parent)
and (more importantly)
ok($subp->is_ancestor($p))
both failed.
while the first I could chalk up as a perl oddity (same C pointer with a different perl address?), the second lead me to believe that something is amuck in the pool creation code. from the look of the mod_perl interface, I suspect it's not specific to mod_perl.
personally, I'd rather not remove anything in the test suite - the tests show exactly how it _ought_ to behave, and it seems to to the right thing for non Win32 systems.
I would prefer just to skip the tests on Win32 and keep the test (and underlying implementation) around.
--Geoff
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
