You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@apr.apache.org by Sander Striker <st...@apache.org> on 2008/04/14 22:05:13 UTC
Re: svn commit: r647394 - in /apr/apr/trunk: CHANGES include/apr_pools.h memory/unix/apr_pools.c
On Mon, Apr 14, 2008 at 9:43 PM, Joe Orton <jo...@redhat.com> wrote:
> On Sat, Apr 12, 2008 at 08:42:59AM -0000, Mladen Turk wrote:
> > Author: mturk
> > Date: Sat Apr 12 01:42:51 2008
> > New Revision: 647394
> >
> > URL: http://svn.apache.org/viewvc?rev=647394&view=rev
> > Log:
> > Introduce apr_pool_sys_allocator_set
>
> Why can't you just use a custom allocator for whatever the problem is
> here? That's what the allocator abstraction is *for*, right? Adding
> yet another abstraction above the allocator seems really wrong;
> especially since it introduces a bunch of global state and *everybody*
> suffers the overhead of the additional function calls and conditionals.
Indeed. We went through quite a few iterations of performance testing
and tweaks to get to where we are. Note that we introduced a memory
allocation system with more abstractions before... we punted on that once
we found out when it caused too much overhead.
Cheers,
Sander
Re: svn commit: r647394 - in /apr/apr/trunk: CHANGES include/apr_pools.h
memory/unix/apr_pools.c
Posted by Mladen Turk <mt...@apache.org>.
William A. Rowe, Jr. wrote:
> Ruediger Pluem wrote:
>>
>> But now that we have branched 1.3.0 we have to live with it until 2.0,
>> right?
>> Maybe branching just 48 hours after these commits wasn't such a good idea
>> especially with these 48 hours being a weekend after ApacheCon.
>
> We have *branched* 1.3.x, we have not *tagged* 1.3.0.
>
> I'm going to hold off several days until the 1.3.0 api is settled, there's
> obvious issues for some of the new features.
Think I'll revert the apr_pool_sys_allocator_set both from
1.3.x branch and from the head.
I admit it was done in a hurry so both API and
intended usage is not polished. The proper memory profiling
and custom system allocation API needs to be done much
better then my patch does.
I'll continue development in head, but probably by using
compile time define APR_POOL_PROFILE (similar to APR_POOL_DEBUG)
Regards
--
(TM)
Re: svn commit: r647394 - in /apr/apr/trunk: CHANGES include/apr_pools.h
memory/unix/apr_pools.c
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
Ruediger Pluem wrote:
>
> But now that we have branched 1.3.0 we have to live with it until 2.0,
> right?
> Maybe branching just 48 hours after these commits wasn't such a good idea
> especially with these 48 hours being a weekend after ApacheCon.
We have *branched* 1.3.x, we have not *tagged* 1.3.0.
I'm going to hold off several days until the 1.3.0 api is settled, there's
obvious issues for some of the new features. So these can be reverted on
1.3.x branch, and kept on trunk/1.4 for further development (e.g. to resolve
each of Joe's objections to the ssl/evp code - provided he's ok with leaving
it to the trunk for the time being?)
Re: svn commit: r647394 - in /apr/apr/trunk: CHANGES include/apr_pools.h
memory/unix/apr_pools.c
Posted by Ruediger Pluem <rp...@apache.org>.
On 04/14/2008 10:52 PM, Joe Orton wrote:
> On Mon, Apr 14, 2008 at 10:44:09PM +0200, Ruediger Pluem wrote:
>> But now that we have branched 1.3.0 we have to live with it until 2.0, right?
>> Maybe branching just 48 hours after these commits wasn't such a good idea
>> especially with these 48 hours being a weekend after ApacheCon.
>
> Nothing is fixed in stone on the 1.3.x branch until a 1.3.0 release is
> made and approved. Having the 1.3.x branch there is fine and useful.
Then everything is fine and I agree that it is *very* useful to have the
branch just to iron out such problems. As mentioned I thought and was worried
that we would have to live for a long time we such issues that did not
have enough discussion.
Regards
Rüdiger
Re: svn commit: r647394 - in /apr/apr/trunk: CHANGES include/apr_pools.h memory/unix/apr_pools.c
Posted by Jim Jagielski <ji...@jaguNET.com>.
On Mon, Apr 14, 2008 at 09:52:13PM +0100, Joe Orton wrote:
> On Mon, Apr 14, 2008 at 10:44:09PM +0200, Ruediger Pluem wrote:
> > But now that we have branched 1.3.0 we have to live with it until 2.0, right?
> > Maybe branching just 48 hours after these commits wasn't such a good idea
> > especially with these 48 hours being a weekend after ApacheCon.
>
> Nothing is fixed in stone on the 1.3.x branch until a 1.3.0 release is
> made and approved. Having the 1.3.x branch there is fine and useful.
>
+1. And we shouldn't feel rushed in any way by what is going
on in httpd-land either :)
--
===========================================================================
Jim Jagielski [|] jim@jaguNET.com [|] http://www.jaguNET.com/
"Great is the guilt of an unnecessary war" ~ John Adams
Re: svn commit: r647394 - in /apr/apr/trunk: CHANGES
include/apr_pools.h memory/unix/apr_pools.c
Posted by Joe Orton <jo...@redhat.com>.
On Mon, Apr 14, 2008 at 10:44:09PM +0200, Ruediger Pluem wrote:
> But now that we have branched 1.3.0 we have to live with it until 2.0, right?
> Maybe branching just 48 hours after these commits wasn't such a good idea
> especially with these 48 hours being a weekend after ApacheCon.
Nothing is fixed in stone on the 1.3.x branch until a 1.3.0 release is
made and approved. Having the 1.3.x branch there is fine and useful.
joe
Re: svn commit: r647394 - in /apr/apr/trunk: CHANGES include/apr_pools.h
memory/unix/apr_pools.c
Posted by Ruediger Pluem <rp...@apache.org>.
On 04/14/2008 10:05 PM, Sander Striker wrote:
> On Mon, Apr 14, 2008 at 9:43 PM, Joe Orton <jo...@redhat.com> wrote:
>> On Sat, Apr 12, 2008 at 08:42:59AM -0000, Mladen Turk wrote:
>> > Author: mturk
>> > Date: Sat Apr 12 01:42:51 2008
>> > New Revision: 647394
>> >
>> > URL: http://svn.apache.org/viewvc?rev=647394&view=rev
>> > Log:
>> > Introduce apr_pool_sys_allocator_set
>>
>> Why can't you just use a custom allocator for whatever the problem is
>> here? That's what the allocator abstraction is *for*, right? Adding
>> yet another abstraction above the allocator seems really wrong;
>> especially since it introduces a bunch of global state and *everybody*
>> suffers the overhead of the additional function calls and conditionals.
>
> Indeed. We went through quite a few iterations of performance testing
> and tweaks to get to where we are. Note that we introduced a memory
> allocation system with more abstractions before... we punted on that once
> we found out when it caused too much overhead.
But now that we have branched 1.3.0 we have to live with it until 2.0, right?
Maybe branching just 48 hours after these commits wasn't such a good idea
especially with these 48 hours being a weekend after ApacheCon.
Regards
Rüdiger