You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@apr.apache.org by br...@apache.org on 2005/07/16 05:56:11 UTC
svn commit: r219285 - /apr/apr/branches/1.1.x/STATUS
Author: brianp
Date: Fri Jul 15 20:56:08 2005
New Revision: 219285
URL: http://svn.apache.org/viewcvs?rev=219285&view=rev
Log:
add a proposed backport from 1.2
Modified:
apr/apr/branches/1.1.x/STATUS
Modified: apr/apr/branches/1.1.x/STATUS
URL: http://svn.apache.org/viewcvs/apr/apr/branches/1.1.x/STATUS?rev=219285&r1=219284&r2=219285&view=diff
==============================================================================
--- apr/apr/branches/1.1.x/STATUS (original)
+++ apr/apr/branches/1.1.x/STATUS Fri Jul 15 20:56:08 2005
@@ -30,6 +30,15 @@
CURRENT VOTES:
+ *) Backport r209931 from 1.2 development trunk:
+ "Switch to lazy initialization of the pollset that's used within
+ apr_file_t on platforms where apr_wait_for_io_or_timeout() doesn't
+ use poll(2). (This fixes a performance problem observed in httpd-2.x
+ on OS X due to the use of poll now being disabled by default on that
+ platform.)"
+ +1: brianp
+ 0:
+ -1:
CURRENT test/testall -v EXCEPTIONS:
Re: svn commit: r219285 - /apr/apr/branches/1.1.x/STATUS
Posted by Brian Pane <br...@brianp.net>.
Thanks. Are you +1 for backporting to both apr-1.1 and apr-1.0? (I
put in a separate
vote in 1.0's STATUS file, since that has the same code for creating
the pollset.)
Can a couple of other cast votes on this?
Thanks,
Brian
On Jul 15, 2005, at 11:13 PM, William A. Rowe, Jr. wrote:
> ++1 - obviously there are some heuristics to determine which
> is the win - but you've identified a pretty clear case where
> our preemptive strategy for creating a pollset was 'a bad idea' :)
>
>
>> + *) Backport r209931 from 1.2 development trunk:
>> + "Switch to lazy initialization of the pollset that's used
>> within
>> + apr_file_t on platforms where apr_wait_for_io_or_timeout()
>> doesn't
>> + use poll(2). (This fixes a performance problem observed in
>> httpd-2.x
>> + on OS X due to the use of poll now being disabled by default
>> on that
>> + platform.)"
>> + +1: brianp
>> + 0:
>> + -1:
>>
>> CURRENT test/testall -v EXCEPTIONS:
>>
>>
>
>
>
Re: svn commit: r219285 - /apr/apr/branches/1.1.x/STATUS
Posted by Joe Orton <jo...@redhat.com>.
On Mon, Jul 18, 2005 at 11:22:15PM -0700, Brian Pane wrote:
> Thanks. Are you +1 for backporting to both apr-1.1 and apr-1.0? (I
> put in a separate vote in 1.0's STATUS file, since that branch has the
> same code for creating the pollset.)
>
> Can a couple of other committers please cast votes on this, too?
There's no need to get votes for backports to APR stable branches; just
backport it if you think that's appropriate, and someone will scream if
they don't like it.
It looks OK to me except that you've used an int rather than an
apr_status_t to store an error code, which should really be fixed:
+ if (file->pollset != NULL) {
+ int pollset_rv = apr_pollset_destroy(file->pollset);
Regards,
joe
Re: svn commit: r219285 - /apr/apr/branches/1.1.x/STATUS
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
At 01:22 AM 7/19/2005, Brian Pane wrote:
>Thanks. Are you +1 for backporting to both apr-1.1 and apr-1.0? (I
>put in a separate
>vote in 1.0's STATUS file, since that branch has the same code for
>creating the pollset.)
I don't have a preference, but really don't see any likelyhood
that we will ever release another 1.0.x, and probably unlikely
that we will release 1.1.x again.
Much different than apr-0 v.s. apr-1. We should be able to pull
a new apr-1 release and have it serve anyone who was previously
using an earlier apr-1.x.
Bill
Re: svn commit: r219285 - /apr/apr/branches/1.1.x/STATUS
Posted by Brian Pane <br...@apache.org>.
Thanks. Are you +1 for backporting to both apr-1.1 and apr-1.0? (I
put in a separate
vote in 1.0's STATUS file, since that branch has the same code for
creating the pollset.)
Can a couple of other committers please cast votes on this, too?
Thanks,
Brian
On Jul 15, 2005, at 11:13 PM, William A. Rowe, Jr. wrote:
> ++1 - obviously there are some heuristics to determine which
> is the win - but you've identified a pretty clear case where
> our preemptive strategy for creating a pollset was 'a bad idea' :)
>
>
>> + *) Backport r209931 from 1.2 development trunk:
>> + "Switch to lazy initialization of the pollset that's used
>> within
>> + apr_file_t on platforms where apr_wait_for_io_or_timeout()
>> doesn't
>> + use poll(2). (This fixes a performance problem observed in
>> httpd-2.x
>> + on OS X due to the use of poll now being disabled by default
>> on that
>> + platform.)"
>> + +1: brianp
>> + 0:
>> + -1:
>>
>> CURRENT test/testall -v EXCEPTIONS:
>>
>>
>
>
>
Re: svn commit: r219285 - /apr/apr/branches/1.1.x/STATUS
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
++1 - obviously there are some heuristics to determine which
is the win - but you've identified a pretty clear case where
our preemptive strategy for creating a pollset was 'a bad idea' :)
>+ *) Backport r209931 from 1.2 development trunk:
>+ "Switch to lazy initialization of the pollset that's used within
>+ apr_file_t on platforms where apr_wait_for_io_or_timeout() doesn't
>+ use poll(2). (This fixes a performance problem observed in httpd-2.x
>+ on OS X due to the use of poll now being disabled by default on that
>+ platform.)"
>+ +1: brianp
>+ 0:
>+ -1:
>
> CURRENT test/testall -v EXCEPTIONS:
>
Re: svn commit: r219285 - /apr/apr/branches/1.1.x/STATUS
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
++1 - obviously there are some heuristics to determine which
is the win - but you've identified a pretty clear case where
our preemptive strategy for creating a pollset was 'a bad idea' :)
>+ *) Backport r209931 from 1.2 development trunk:
>+ "Switch to lazy initialization of the pollset that's used within
>+ apr_file_t on platforms where apr_wait_for_io_or_timeout() doesn't
>+ use poll(2). (This fixes a performance problem observed in httpd-2.x
>+ on OS X due to the use of poll now being disabled by default on that
>+ platform.)"
>+ +1: brianp
>+ 0:
>+ -1:
>
> CURRENT test/testall -v EXCEPTIONS:
>