perl-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jan Kaluža <jkal...@redhat.com>
Subject Re: release blockers?
Date Tue, 16 Sep 2014 07:08:54 GMT
On 09/12/2014 07:05 PM, Steve Hay wrote:
> On 12 September 2014 16:15, Niko Tyni <ntyni@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).

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.

Jan Kaluza

> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
> For additional commands, e-mail: dev-help@perl.apache.org
>


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org


Mime
View raw message