Return-Path: X-Original-To: apmail-perl-dev-archive@www.apache.org Delivered-To: apmail-perl-dev-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id 797E217CF1 for ; Thu, 16 Oct 2014 08:02:40 +0000 (UTC) Received: (qmail 29752 invoked by uid 500); 16 Oct 2014 08:02:40 -0000 Delivered-To: apmail-perl-dev-archive@perl.apache.org Received: (qmail 29718 invoked by uid 500); 16 Oct 2014 08:02:40 -0000 Mailing-List: contact dev-help@perl.apache.org; run by ezmlm Precedence: bulk list-help: list-unsubscribe: List-Post: List-Id: Delivered-To: mailing list dev@perl.apache.org Received: (qmail 29707 invoked by uid 99); 16 Oct 2014 08:02:39 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 16 Oct 2014 08:02:39 +0000 X-ASF-Spam-Status: No, hits=1.5 required=5.0 tests=HTML_MESSAGE,RCVD_IN_DNSWL_LOW,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (nike.apache.org: domain of steve.m.hay@googlemail.com designates 209.85.214.182 as permitted sender) Received: from [209.85.214.182] (HELO mail-ob0-f182.google.com) (209.85.214.182) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 16 Oct 2014 08:02:13 +0000 Received: by mail-ob0-f182.google.com with SMTP id uy5so2479607obc.27 for ; Thu, 16 Oct 2014 01:02:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=L+e2NZ9ShleszV0DssQFF4jpP5ZBrnaMgXb6RhGuGco=; b=0XG6gpPK5Lgfc/eumXo7B/GpiBba/lDFVsp/orai/hukqocwaWhwAbMfT0Kj8Iflxc ncRv+NVdmameb3izYjeOXJSrkUbaeF5CBhWL/ibbl9UUHBK8XnIgLSyKYHA9sN95Vzni 7ttJGvnjUCooWdU2/X4J2Sez/1pICelilkcx3Ku/t7+XLAoll/2Aj+iaqnmT49hESRPR Rkvr+NueF9ae2JRvFYj/CLxWp3S+SlO7HOpOCa1nyeMvC/c0etD1HlnxPKY3ZGp1klsJ l6XrNAD7Yvhh6HGUtg7K52W+KcAIGkR4bKDft9iEA6iaTk8BeCILmQbXlv2FcWoCNdAi rihg== MIME-Version: 1.0 X-Received: by 10.60.48.4 with SMTP id h4mr1022587oen.42.1413446532354; Thu, 16 Oct 2014 01:02:12 -0700 (PDT) Received: by 10.60.167.4 with HTTP; Thu, 16 Oct 2014 01:02:12 -0700 (PDT) In-Reply-To: <5417E206.6070308@redhat.com> References: <53FDAB06.4060906@redhat.com> <54130AD0.7090509@redhat.com> <20140912151511.GA3767@estella.local.invalid> <5417E206.6070308@redhat.com> Date: Thu, 16 Oct 2014 09:02:12 +0100 Message-ID: Subject: Re: release blockers? From: Steve Hay To: =?UTF-8?Q?Jan_Kalu=C5=BEa?= Cc: mod_perl Dev Content-Type: multipart/alternative; boundary=001a1134c73279837d050585aaa9 X-Virus-Checked: Checked by ClamAV on apache.org --001a1134c73279837d050585aaa9 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 16 September 2014 08:08, Jan Kalu=C5=BEa wrote: > On 09/12/2014 07:05 PM, Steve Hay wrote: > >> On 12 September 2014 16:15, Niko Tyni wrote: >> >>> On Fri, Sep 12, 2014 at 05:01:36PM +0200, Jan Kalu=C5=BEa wrote: >>> >>>> On 08/27/2014 11:55 AM, Jan Kalu=C5=BEa 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 i= s > 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 onc= e > 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 i= ts > 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. --001a1134c73279837d050585aaa9 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On 1= 6 September 2014 08:08, Jan Kalu=C5=BEa <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=C5=BEa wrote:
On 08/27/2014 11:55 AM, Jan Kalu=C5=BEa 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?

=C2=A0 = 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 d= oesn't fail for me since the test requires the worker MPM, so is skippe= d on Windows!

=C2=A0

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:

=C2=A0 =C2=A0 # now add an extra PerlCleanupHandler. It is run each time th= e
=C2=A0 =C2=A0 # interp is released. So it is run after Trans, MapToStorage = and
=C2=A0 =C2=A0 # Fixup. In the response phase $counter should be 5. After Re= sponse
=C2=A0 =C2=A0 # 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 t= he comment.

It then continues with:

=C2=A0 =C2=A0 # This used to eat up all interpreters because
=C2=A0 =C2=A0 # modperl_interp_unselect
=C2=A0 =C2=A0 # calls modperl_config_request_cleanup that allocates a new i= nterp
=C2=A0 =C2=A0 # to handle the cleanup.

This is also not a true in current code. modperl_interp_unselect does not c= all 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 c= learly 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 long= er have.


Now omitted fro= m the distribution as per Niko's suggestion: Revision 1632231.
--001a1134c73279837d050585aaa9--