perl-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Steve Hay <steve.m....@googlemail.com>
Subject Re: release blockers?
Date Thu, 16 Oct 2014 08:02:12 GMT
On 16 September 2014 08:08, Jan Kaluža <jkaluza@redhat.com> wrote:

> 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).
>>
>
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.

Mime
View raw message