On 16 September 2014 08:08, Jan Kaluža <jkal...@redhat.com> wrote: > On 09/12/2014 07:05 PM, Steve Hay wrote: > >> On 12 September 2014 16:15, Niko Tyni <nt...@debian.org> wrote: >> >>> On Fri, Sep 12, 2014 at 05:01:36PM +0200, Jan Kaluža wrote: >>> >>>> On 08/27/2014 11:55 AM, Jan Kaluža wrote: >>>> >>>>> >>>>> since we have mod_perl which compiles and works with httpd-2.4, what >>>>> are >>>>> the current blockers before we do some release with initial httpd-2.4 >>>>> support? >>>>> >>>> >>>> Does the silence mean that we have no blockers? :) >>>> >>> >>> Is t/perl/ithreads3.t working for everybody else? >>> >>> http://mail-archives.apache.org/mod_mbox/perl-dev/201408. >>> mbox/%3C20140807141231.GA24545@estella.local.invalid%3E >>> >>> >> Works for me last time I tried, but t/perl/ithreads* are not in the >> release tarballs anyway, I think (because of persistent trouble with >> them historically). >> > It doesn't actually "work for me", of course: It just doesn't fail for me since the test requires the worker MPM, so is skipped on Windows!
> > I've tried it with worker MPM and it fails for me, but I think the test is > somehow broken. The comment in ithreads3.pm says: > > # now add an extra PerlCleanupHandler. It is run each time the > # interp is released. So it is run after Trans, MapToStorage and > # Fixup. In the response phase $counter should be 5. After Response > # it is run again but that is after. > > But when checking the code for PerlCleanupHandler, it seems to be run once > the request request_rec.pool is destroyed, which is in contradiction with > the comment. > > It then continues with: > > # This used to eat up all interpreters because > # modperl_interp_unselect > # calls modperl_config_request_cleanup that allocates a new interp > # to handle the cleanup. > > This is also not a true in current code. modperl_interp_unselect does not > call modperl_config_request_cleanup if I understand the current code. > > I would say the test is outdated and I have no clue what was its goal. It > clearly tries to count how many times are the handlers executed, but in its > current state, it is not useful, because it tests the code paths we no > longer have. > > Now omitted from the distribution as per Niko's suggestion: Revision 1632231.
