You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@perl.apache.org by Jan Kaluža <jk...@redhat.com> on 2014/08/27 11:55:18 UTC
release blockers?
Hi,
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?
Distributions tend to use our trunk anyway, so maybe it's time to think
about some beta release with httpd-2.4 support :).
Jan Kaluza
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: release blockers?
Posted by Jan Kaluža <jk...@redhat.com>.
On 09/12/2014 07:06 PM, Steve Hay wrote:
> On 12 September 2014 18:01, Fred Moyer <fr...@redhotpenguin.com> wrote:
>> On Wed, Aug 27, 2014 at 2:55 AM, Jan Kaluža <jk...@redhat.com> 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?
>>
>> What branch should I pull for testing? Or has that code been merged into trunk?
>>
>>
>
> Everything's in trunk now.
>
> I think we're good to go. I have a couple of failure on Windows still,
> but wouldn't want to hold people up on other OSes for them if it's
> looking good elsewhere.
>
Time for Christmas release? :)
Regards,
Jan Kaluza
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: release blockers?
Posted by Steve Hay <st...@googlemail.com>.
On 12 September 2014 18:01, Fred Moyer <fr...@redhotpenguin.com> wrote:
> On Wed, Aug 27, 2014 at 2:55 AM, Jan Kaluža <jk...@redhat.com> 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?
>
> What branch should I pull for testing? Or has that code been merged into trunk?
>
>
Everything's in trunk now.
I think we're good to go. I have a couple of failure on Windows still,
but wouldn't want to hold people up on other OSes for them if it's
looking good elsewhere.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: release blockers?
Posted by Fred Moyer <fr...@redhotpenguin.com>.
On Wed, Aug 27, 2014 at 2:55 AM, Jan Kaluža <jk...@redhat.com> 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?
What branch should I pull for testing? Or has that code been merged into trunk?
>
> Distributions tend to use our trunk anyway, so maybe it's time to think
> about some beta release with httpd-2.4 support :).
>
> 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
Re: release blockers?
Posted by Andres Thomas Stivalet <at...@gmail.com>.
Might not be the place for it, but does anybody really use ithreads in a
mod_perl enviro? That just sounds insane.
On Fri, Sep 12, 2014 at 10:15 AM, 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
>
> --
> Niko Tyni ntyni@debian.org
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
> For additional commands, e-mail: dev-help@perl.apache.org
>
>
Re: release blockers?
Posted by Niko Tyni <nt...@debian.org>.
On Fri, Sep 12, 2014 at 06:05:57PM +0100, Steve Hay wrote:
> On 12 September 2014 16:15, Niko Tyni <nt...@debian.org> wrote:
> > 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).
Looks like the DATA section in lib/ModPerl/Manifest.pm lists ithreads.t
and ithreads2.t, but doesn't have a wildcard. Maybe add ithreads3.t there?
--
Niko Tyni ntyni@debian.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: release blockers?
Posted by Steve Hay <st...@googlemail.com>.
On 16 October 2014 10:11, Jan Kaluža <jk...@redhat.com> wrote:
> On 10/16/2014 10:02 AM, Steve Hay wrote:
>>
>> On 16 September 2014 08:08, Jan Kaluža <jkaluza@redhat.com
>> <ma...@redhat.com>> wrote:
>>
>> On 09/12/2014 07:05 PM, Steve Hay wrote:
>>
>> On 12 September 2014 16:15, Niko Tyni <ntyni@debian.org
>> <ma...@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?
>>
[...]
>>
>> Now omitted from the distribution as per Niko's suggestion: Revision
>> 1632231.
>
>
> Great, thanks. Do you know anything else we have to do/fix before release?
> :) I would like to so see some release with 2.4.x support soon :).
>
I still have failing tests on Windows, but have all but given up
trying to fix them prior to release. We'll just have to add a "Known
Problems" note somewhere since the tests are working fine on other
OSes.
I would also like to see a 2.4-compatible release soon, and will
hopefully get one out very soon now with the kindly volunteered help
of gozer :-)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: release blockers?
Posted by Jan Kaluža <jk...@redhat.com>.
On 10/16/2014 10:02 AM, Steve Hay wrote:
> On 16 September 2014 08:08, Jan Kaluža <jkaluza@redhat.com
> <ma...@redhat.com>> wrote:
>
> On 09/12/2014 07:05 PM, Steve Hay wrote:
>
> On 12 September 2014 16:15, Niko Tyni <ntyni@debian.org
> <ma...@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
> <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
> <http://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.
Great, thanks. Do you know anything else we have to do/fix before
release? :) I would like to so see some release with 2.4.x support soon :).
Regards,
Jan Kaluza
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: release blockers?
Posted by Steve Hay <st...@googlemail.com>.
On 16 September 2014 08:08, Jan Kaluža <jk...@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.
Re: release blockers?
Posted by Steve Hay <st...@googlemail.com>.
On 16 October 2014 11:13, Torsten Förtsch <to...@gmx.net> wrote:
> On 16/09/14 09:08, Jan Kaluža wrote:
>>> 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.
>
> Back around 2.0.4 or so, we had several bug regarding interpreter
> allocation/deallocation. I especially remember 2. The first one
> allocated a separate interpreter for the response phase. So, you got
> different interpreters for fixup and response for instance. Then we had
> a complete mess with "PerlInterpScope handler". Perhaps the test is for
> one of these cases.
>
> We also had a bug that a PerlCleanupHandler was not called at all if
> another perl handler hadn't been invoked prior in the request cycle. Not
> sure if we have a test for that or if we even have fixed it.
It looks like it was fixed by revision 594609 on the threading branch,
which I merged into httpd24threading and then into trunk.
>
> I think all of these bugs should have been eliminated with the change
> from simple flag-based interpreter management to refcount-based. I
> believe this is what the current code is based upon, right?
>
Yes, all of the work you did (some of it committed by gozer) on the
threading branch is now in trunk. In particular, revision 594601 is
the one that introduced ref-counted interpreter management for
threaded MPMs.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: release blockers?
Posted by Torsten Förtsch <to...@gmx.net>.
On 16/09/14 09:08, Jan Kaluža wrote:
>> 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.
Back around 2.0.4 or so, we had several bug regarding interpreter
allocation/deallocation. I especially remember 2. The first one
allocated a separate interpreter for the response phase. So, you got
different interpreters for fixup and response for instance. Then we had
a complete mess with "PerlInterpScope handler". Perhaps the test is for
one of these cases.
We also had a bug that a PerlCleanupHandler was not called at all if
another perl handler hadn't been invoked prior in the request cycle. Not
sure if we have a test for that or if we even have fixed it.
I think all of these bugs should have been eliminated with the change
from simple flag-based interpreter management to refcount-based. I
believe this is what the current code is based upon, right?
Torsten
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: release blockers?
Posted by Jan Kaluža <jk...@redhat.com>.
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).
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
Re: release blockers?
Posted by Steve Hay <st...@googlemail.com>.
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).
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: release blockers?
Posted by Niko Tyni <nt...@debian.org>.
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
--
Niko Tyni ntyni@debian.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: release blockers?
Posted by Jan Kaluža <jk...@redhat.com>.
On 08/27/2014 11:55 AM, Jan Kaluža wrote:
> Hi,
>
> 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? :)
Jan Kaluza
> Distributions tend to use our trunk anyway, so maybe it's time to think
> about some beta release with httpd-2.4 support :).
>
> 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