You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@apr.apache.org by Justin Erenkrantz <ju...@erenkrantz.com> on 2009/01/03 20:33:12 UTC
Re: On to APR 2.0.0? Beyond 9x/ME
On Fri, Jan 2, 2009 at 3:57 PM, William A. Rowe, Jr.
<wr...@rowe-clan.net> wrote:
> I don't know that we have any active interest in 2.0.0 at this moment,
Since I guess trunk is now 2.0.0, here's what I'd like to see:
1. fold in apr-util and apr-iconv into apr trunk.
2. move to a SCons-build system (if you don't have Python available in
2009, your OS sucks)
3. make pools runtime-configurable whether they are just a thin
malloc()/free() wrapper or do internal reuse
I'm volunteering to do the grunt work for 1. I think I know someone
who might volunteer for #2 (*nudge*). And, #3 shouldn't be terribly
hard to accomplish as long as we keep the pool API the same. If we
want to tweak the pool API, then that's far more involved.
Thoughts? -- justin
Re: On to APR 2.0.0? Beyond 9x/ME
Posted by Branko Čibej <br...@xbc.nu>.
Mladen Turk wrote:
> Branko Čibej wrote:
>> Graham Leggett wrote:
>>> Branko Čibej wrote:
>>>
>>>> Oh, certainly. Except that sometimes the "just" is a pretty big one. I
>>>> remember once ... well, to make a long story short, control over pool
>>>> lifetime wasn't, and we ended up jumping through several Klein bottles
>>>> to get there.
>>> Unless I am not following something, you control the pool lifetime.
>>
>> Not if you have no control of pool cleanup order, which is exactly what
>> happens when you try to allocate long-lived structure in a DSO; the way
>> we do pool cleanup guarantees that the DSO gets unloaded before any
>> global pools are cleaned up.
>>
>> You could say that the answer is "don't do that", but sometimes there's
>> no other option.
>>
>
> There is a new apr_poll_pre_cleanup_register API, meant to
> be used exactly for that. It ensures that cleanup will run
> before subpools gets destroyed.
*Now* there is. Might be enough for the case I mentioned, dunno --
frankly I haven't looked it in a while. (Not that it would help SVN 1.x,
but that's irrelevant).
Re: On to APR 2.0.0? Beyond 9x/ME
Posted by Mladen Turk <mt...@apache.org>.
Branko Čibej wrote:
> Graham Leggett wrote:
>> Branko Čibej wrote:
>>
>>> Oh, certainly. Except that sometimes the "just" is a pretty big one. I
>>> remember once ... well, to make a long story short, control over pool
>>> lifetime wasn't, and we ended up jumping through several Klein bottles
>>> to get there.
>> Unless I am not following something, you control the pool lifetime.
>
> Not if you have no control of pool cleanup order, which is exactly what
> happens when you try to allocate long-lived structure in a DSO; the way
> we do pool cleanup guarantees that the DSO gets unloaded before any
> global pools are cleaned up.
>
> You could say that the answer is "don't do that", but sometimes there's
> no other option.
>
There is a new apr_poll_pre_cleanup_register API, meant to
be used exactly for that. It ensures that cleanup will run
before subpools gets destroyed.
Regards
--
^(TM)
Re: On to APR 2.0.0? Beyond 9x/ME
Posted by Branko Čibej <br...@xbc.nu>.
Graham Leggett wrote:
> Branko Čibej wrote:
>
>> Oh, certainly. Except that sometimes the "just" is a pretty big one. I
>> remember once ... well, to make a long story short, control over pool
>> lifetime wasn't, and we ended up jumping through several Klein bottles
>> to get there.
>
> Unless I am not following something, you control the pool lifetime.
Not if you have no control of pool cleanup order, which is exactly what
happens when you try to allocate long-lived structure in a DSO; the way
we do pool cleanup guarantees that the DSO gets unloaded before any
global pools are cleaned up.
You could say that the answer is "don't do that", but sometimes there's
no other option.
-- Brane
Re: On to APR 2.0.0? Beyond 9x/ME
Posted by Graham Leggett <mi...@sharp.fm>.
Branko Čibej wrote:
> Oh, certainly. Except that sometimes the "just" is a pretty big one. I
> remember once ... well, to make a long story short, control over pool
> lifetime wasn't, and we ended up jumping through several Klein bottles
> to get there.
Unless I am not following something, you control the pool lifetime.
If you wanted pure emulation of malloc and free, with no pool hierarchy,
just create one global pool, and then create a subpool every time you
want to do malloc, and destroy that subpool every time you want to do
free. Because all of your subpools have no relationship with one another
(apart from being created from the global pool, which would last the
applications' lifetime), lifetime is no longer an issue.
Regards,
Graham
--
Re: On to APR 2.0.0? Beyond 9x/ME
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
Paul Querna wrote:
> Branko Čibej wrote:
>>
>> Oh, certainly. Except that sometimes the "just" is a pretty big one. I
>> remember once ... well, to make a long story short, control over pool
>> lifetime wasn't, and we ended up jumping through several Klein bottles
>> to get there.
>
> I think a proposal to make them optional would be very interesting, I
> know some people (Garrett Rooney?) had some ideas on this.
I've seen a proposal to replace pool_clear/_destroy to call free() instead
of returning the pool to the allocator.
And we've tried implementing apr_sms for pluggable memory in the past,
see the svn history. The performance was unacceptable.
Bill
Re: On to APR 2.0.0? Beyond 9x/ME
Posted by Paul Querna <ch...@force-elite.com>.
Branko Čibej wrote:
> William A. Rowe, Jr. wrote:
>> Branko Čibej wrote:
>>
>>> Justin Erenkrantz wrote:
>>>
>>>> 3. make pools runtime-configurable whether they are just a thin
>>>> malloc()/free() wrapper or do internal reuse
>>>>
>>>>
>>> I think there may be some interest in this ... we've learned the hard
>>> way that pools as they stand today, while moderately nice for stateless
>>> server implementations, are less than moderately horrible for anything else.
>>>
>> Nonsense ;-) It's just a matter of applying the right scope to the right
>> objects, and this is far simpler than anticipating when individual byte
>> allocations are free()ed.
>>
>
> Oh, certainly. Except that sometimes the "just" is a pretty big one. I
> remember once ... well, to make a long story short, control over pool
> lifetime wasn't, and we ended up jumping through several Klein bottles
> to get there.
I think a proposal to make them optional would be very interesting, I
know some people (Garrett Rooney?) had some ideas on this.
Thanks,
Paul
Re: On to APR 2.0.0? Beyond 9x/ME
Posted by Branko Čibej <br...@xbc.nu>.
William A. Rowe, Jr. wrote:
> Branko Čibej wrote:
>
>> Justin Erenkrantz wrote:
>>
>>> 3. make pools runtime-configurable whether they are just a thin
>>> malloc()/free() wrapper or do internal reuse
>>>
>>>
>> I think there may be some interest in this ... we've learned the hard
>> way that pools as they stand today, while moderately nice for stateless
>> server implementations, are less than moderately horrible for anything else.
>>
>
> Nonsense ;-) It's just a matter of applying the right scope to the right
> objects, and this is far simpler than anticipating when individual byte
> allocations are free()ed.
>
Oh, certainly. Except that sometimes the "just" is a pretty big one. I
remember once ... well, to make a long story short, control over pool
lifetime wasn't, and we ended up jumping through several Klein bottles
to get there.
-- Brane
Re: On to APR 2.0.0? Beyond 9x/ME
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
Branko Čibej wrote:
> Justin Erenkrantz wrote:
>> 3. make pools runtime-configurable whether they are just a thin
>> malloc()/free() wrapper or do internal reuse
>>
>
> I think there may be some interest in this ... we've learned the hard
> way that pools as they stand today, while moderately nice for stateless
> server implementations, are less than moderately horrible for anything else.
Nonsense ;-) It's just a matter of applying the right scope to the right
objects, and this is far simpler than anticipating when individual byte
allocations are free()ed.
What just refers to is whether or not apr_pool_clear/_destroy should drop
the memory back into a pool freelist, or back to the system allocator (and
call a true free() upon their release). With modern malloc/free, we may be
looking at very little advantage to keeping a freelist.
Re: On to APR 2.0.0? Beyond 9x/ME
Posted by Mladen Turk <mt...@apache.org>.
Nick Kew wrote:
> On Mon, 16 Feb 2009 08:06:11 +0100
> Mladen Turk <mt...@apache.org> wrote:
>
>> One thing I've proposed (but was vetoed) was the actual
>> malloc/free programmable replacement within the allocator.
>> Now the thing to consider is to make the allocator public
>> allowing to implement what ever system memory allocation
>> there is (eg, heap or virtualmemory on win32, shm, etc)
>> instead just relying on standard allocator implementation
>> which (I presume that 8K granulation was more or less
>> empirically determined) is fixed.
>
> Can you point to that discussion?
Here was the patch
http://svn.apache.org/viewvc?view=rev&revision=647394
Browse the archive for objections ;)
> Seems to me that if it
> can be done without performance penalties, then making the
> allocator into a public API should have potential to be the
> solution to make everyone happy.
>
I'm not saying the the proposed API was perfect.
It only changed the internal allocator malloc/free.
The best thing would be to completely abstract the
allocator so that one can completely implement it's
own allocator.
The existing implementation would then change from:
mem = allocator_alloc(allocator, size)
to
mem = (*allocator->alloc)(allocator, size)
I don't think there will be any performance
penalties using that.
Regards
--
^(TM)
Re: On to APR 2.0.0? Beyond 9x/ME
Posted by Nick Kew <ni...@webthing.com>.
On Mon, 16 Feb 2009 08:06:11 +0100
Mladen Turk <mt...@apache.org> wrote:
> One thing I've proposed (but was vetoed) was the actual
> malloc/free programmable replacement within the allocator.
> Now the thing to consider is to make the allocator public
> allowing to implement what ever system memory allocation
> there is (eg, heap or virtualmemory on win32, shm, etc)
> instead just relying on standard allocator implementation
> which (I presume that 8K granulation was more or less
> empirically determined) is fixed.
Can you point to that discussion? Seems to me that if it
can be done without performance penalties, then making the
allocator into a public API should have potential to be the
solution to make everyone happy.
--
Nick Kew
Re: On to APR 2.0.0? Beyond 9x/ME
Posted by Mladen Turk <mt...@apache.org>.
Branko Čibej wrote:
> Graham Leggett wrote:
>
> I expect that with the new detached global pools in APR, that particular
> problem would never have arisen.
>
Right, that was the point, and that allows the pools
to behave more or less like malloc/free.
One thing I've proposed (but was vetoed) was the actual
malloc/free programmable replacement within the allocator.
Now the thing to consider is to make the allocator public
allowing to implement what ever system memory allocation
there is (eg, heap or virtualmemory on win32, shm, etc)
instead just relying on standard allocator implementation
which (I presume that 8K granulation was more or less
empirically determined) is fixed.
> The fact remains that control of pool lifetimes, whether in combination
> with DSO or long-lived memory structures, is a tricky problem not
> addressed by the current implementation.
>
Detached pools behave like malloc/free and have to be
destroyed manually (well you can always create a pool
cleanup from some standard pool).
Having custom allocators one could even create
smaller (less then default 8K) memory
footprint where system malloc has low fragmentation and
larger number of small pools is required.
Regards
--
^(TM)
Re: On to APR 2.0.0? Beyond 9x/ME
Posted by Branko Čibej <br...@xbc.nu>.
Graham Leggett wrote:
> Branko Čibej wrote:
>
>> I think there may be some interest in this ... we've learned the hard
>> way that pools as they stand today, while moderately nice for stateless
>> server implementations, are less than moderately horrible for
>> anything else.
>
> I strongly disagree.
>
> malloc and free are painful in the extreme, subpools give you all the
> structure of object oriented programming, without the need to touch C++.
I'm quite mystified ... what does memory mangement have to do with OOP?
Or specifically with C++?
> Just replace malloc with apr_pool_create, and replace free with
> apr_pool_destroy, and you are done.
All right, I'll have to expand on that story it seems. But first --
using pool-create/destroy instead of malloc/free is nonsense, as the
former are quite a bit more expensive in that case, and wouldn't have
solved the problem I'm about to describe.
But I digress.
The problem I was refering to was about controlling pool lifetime in a
long-lived process-wide cache where the controlling code happened to be
in a DSO. (It's the DB_REGISTER hack in Subversion, details are in SVN
archives).
What happened was that the "global" pool that the cache was allocated
from was destroyed /after/ the DSO was unloaded, leaving cleanup
functions pointing to non-existent code. While eventually we managed to
work around that problem, it would've been a lot easier if control over
pool lifetimes were more explicit.
I expect that with the new detached global pools in APR, that particular
problem would never have arisen.
The fact remains that control of pool lifetimes, whether in combination
with DSO or long-lived memory structures, is a tricky problem not
addressed by the current implementation.
-- Brane
Re: On to APR 2.0.0? Beyond 9x/ME
Posted by Graham Leggett <mi...@sharp.fm>.
Branko Čibej wrote:
> I think there may be some interest in this ... we've learned the hard
> way that pools as they stand today, while moderately nice for stateless
> server implementations, are less than moderately horrible for anything else.
I strongly disagree.
malloc and free are painful in the extreme, subpools give you all the
structure of object oriented programming, without the need to touch C++.
Just replace malloc with apr_pool_create, and replace free with
apr_pool_destroy, and you are done.
Regards,
Graham
--
Re: On to APR 2.0.0? Beyond 9x/ME
Posted by Branko Čibej <br...@xbc.nu>.
Justin Erenkrantz wrote:
> 3. make pools runtime-configurable whether they are just a thin
> malloc()/free() wrapper or do internal reuse
>
I think there may be some interest in this ... we've learned the hard
way that pools as they stand today, while moderately nice for stateless
server implementations, are less than moderately horrible for anything else.
-- Brane
Re: On to APR 2.0.0? Beyond 9x/ME
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
Graham Leggett wrote:
> William A. Rowe, Jr. wrote:
>
>> The apr_ldap api should either be dumped or made a full abstraction,
>> it's a crufty design.
>
> That's my job, roll on v2.0.
Thanks guy ;-)
About this stub of stubs, I don't understand what Paul describes.
Today we ask the OS to load;
app
\- libapr-2.so
and from apr, on demand;
\- apr_db.so
\-libdbXX.so
What exactly do you propose?
Re: On to APR 2.0.0? Beyond 9x/ME
Posted by Graham Leggett <mi...@sharp.fm>.
William A. Rowe, Jr. wrote:
> The apr_ldap api should either be dumped or made a full abstraction,
> it's a crufty design.
That's my job, roll on v2.0.
Regards,
Graham
--
Re: On to APR 2.0.0? Beyond 9x/ME
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
Paul Querna wrote:
> William A. Rowe, Jr. wrote:
>> Justin Erenkrantz wrote:
>>> On Fri, Jan 2, 2009 at 3:57 PM, William A. Rowe, Jr.
>>> <wr...@rowe-clan.net> wrote:
>>>> I don't know that we have any active interest in 2.0.0 at this moment,
>>> Since I guess trunk is now 2.0.0, here's what I'd like to see:
>>>
>>> 1. fold in apr-util
>>
>> +1, with the dso approach, it is not so harmful for apps to link to it,
>> and it solves the mutex initialization problems reported by Joe. If this
>> means apr-util/trunk disappears, that's fine.
>
> Yeah, we need to sketch out how the DSO loading works API wise, and do
> it in a generic way, such that most of the symbols exist in the main
> library, but at runtime we can pull in a bunch of libraries.
>
> For example, apr_ldap_open or apr_dbm_open should exist, but we
> shouldn't hard link to libldap or libdb46 instead perhaps have shim
> shared DSOs that we load, libapr-ldap.so, which are linked to them. I
> think an approach like this could work on most Linux/BSD/OSX type
> places, but I'm sure it will have problems on some rarer unix OS.
We don't hard link to libdbXX anymore :) Catch up with us here LOL.
The apr_ldap api should either be dumped or made a full abstraction,
it's a crufty design.
> But doing this is anotheer reason to do it in SCons, it would make all
> the dynamic/static libs compiling much easier.
Hmmm. I'm far from convinced, you'll have to demonstrate a flaw in the
current schema to convince me :)
>>> and apr-iconv into apr trunk.
>>
>> -1; we need a different solution. citrus, something based on the work of
>> the perl community (automated), or even IBM's ICU. There isn't the long
>> term interest in maintaining this.
>
> Do we even need it at all? Can't we just remove it and tell people to
> use IBM's ICU? (or another library?)
That's the point. Maybe multiple interfaces from apr_xlate into icu
(I didn't see the mapping, but this is a version major bump so we might be
able to identify a common api) or libiconv. Either way, this falls into the
dso binding strategy as well.
Re: On to APR 2.0.0? Beyond 9x/ME
Posted by Justin Erenkrantz <ju...@erenkrantz.com>.
On Sat, Jan 3, 2009 at 1:05 PM, Paul Querna <ch...@force-elite.com> wrote:
> don't think it matters too much, I've just started with core libapr first --
> apr-util means just adding more detection code and making shared libs out of
> some files....
Yah, I think it'd be slightly easier to get to a buildable system if
we convert libapr to SCons and then import in apr-util. Otherwise, it
means merging the auto-fu/make systems (which aren't the same) as well
and then just adding the SCons bits... -- justin
Re: On to APR 2.0.0? Beyond 9x/ME
Posted by Paul Querna <ch...@force-elite.com>.
Justin Erenkrantz wrote:
> On Sat, Jan 3, 2009 at 12:45 PM, Paul Querna <ch...@force-elite.com> wrote:
>> #2 is mine I guess :P
>
> Does it make sense to rejigger the build system first, then fold in
> apr-util? Vice versa? Same time? -- justin
don't think it matters too much, I've just started with core libapr
first -- apr-util means just adding more detection code and making
shared libs out of some files....
Re: On to APR 2.0.0? Beyond 9x/ME
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
Justin Erenkrantz wrote:
> On Sat, Jan 3, 2009 at 12:45 PM, Paul Querna <ch...@force-elite.com> wrote:
>> #2 is mine I guess :P
>
> Does it make sense to rejigger the build system first, then fold in
> apr-util? Vice versa? Same time? -- justin
Folding apr-util into apr should be pretty painless, using the autoconf,
and then we can start "from scratch" on new build schemas.
Re: On to APR 2.0.0? Beyond 9x/ME
Posted by Justin Erenkrantz <ju...@erenkrantz.com>.
On Sat, Jan 3, 2009 at 12:45 PM, Paul Querna <ch...@force-elite.com> wrote:
> #2 is mine I guess :P
Does it make sense to rejigger the build system first, then fold in
apr-util? Vice versa? Same time? -- justin
Re: On to APR 2.0.0? Beyond 9x/ME
Posted by Paul Querna <ch...@force-elite.com>.
William A. Rowe, Jr. wrote:
> Justin Erenkrantz wrote:
>> On Fri, Jan 2, 2009 at 3:57 PM, William A. Rowe, Jr.
>> <wr...@rowe-clan.net> wrote:
>>> I don't know that we have any active interest in 2.0.0 at this moment,
>> Since I guess trunk is now 2.0.0, here's what I'd like to see:
>>
>> 1. fold in apr-util
>
> +1, with the dso approach, it is not so harmful for apps to link to it,
> and it solves the mutex initialization problems reported by Joe. If this
> means apr-util/trunk disappears, that's fine.
Yeah, we need to sketch out how the DSO loading works API wise, and do
it in a generic way, such that most of the symbols exist in the main
library, but at runtime we can pull in a bunch of libraries.
For example, apr_ldap_open or apr_dbm_open should exist, but we
shouldn't hard link to libldap or libdb46 instead perhaps have shim
shared DSOs that we load, libapr-ldap.so, which are linked to them. I
think an approach like this could work on most Linux/BSD/OSX type
places, but I'm sure it will have problems on some rarer unix OS.
But doing this is anotheer reason to do it in SCons, it would make all
the dynamic/static libs compiling much easier.
>> and apr-iconv into apr trunk.
>
> -1; we need a different solution. citrus, something based on the work of
> the perl community (automated), or even IBM's ICU. There isn't the long
> term interest in maintaining this.
Do we even need it at all? Can't we just remove it and tell people to
use IBM's ICU? (or another library?)
>> 2. move to a SCons-build system (if you don't have Python available in
>> 2009, your OS sucks)
>
> Create a sandbox, demonstrate it. Same goes for cmake fans. Time for a
> shootout to eliminate our current headaches.
>
>> 3. make pools runtime-configurable whether they are just a thin
>> malloc()/free() wrapper or do internal reuse
>
> Interesting, looking forwards to patches :)
Huge +1 to doing this.
>> I'm volunteering to do the grunt work for 1. I think I know someone
>> who might volunteer for #2 (*nudge*). And, #3 shouldn't be terribly
>> hard to accomplish as long as we keep the pool API the same. If we
>> want to tweak the pool API, then that's far more involved.
#2 is mine I guess :P
-Paul
Re: On to APR 2.0.0? Beyond 9x/ME
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
Justin Erenkrantz wrote:
> On Fri, Jan 2, 2009 at 3:57 PM, William A. Rowe, Jr.
> <wr...@rowe-clan.net> wrote:
>> I don't know that we have any active interest in 2.0.0 at this moment,
>
> Since I guess trunk is now 2.0.0, here's what I'd like to see:
>
> 1. fold in apr-util
+1, with the dso approach, it is not so harmful for apps to link to it,
and it solves the mutex initialization problems reported by Joe. If this
means apr-util/trunk disappears, that's fine.
> and apr-iconv into apr trunk.
-1; we need a different solution. citrus, something based on the work of
the perl community (automated), or even IBM's ICU. There isn't the long
term interest in maintaining this.
> 2. move to a SCons-build system (if you don't have Python available in
> 2009, your OS sucks)
Create a sandbox, demonstrate it. Same goes for cmake fans. Time for a
shootout to eliminate our current headaches.
> 3. make pools runtime-configurable whether they are just a thin
> malloc()/free() wrapper or do internal reuse
Interesting, looking forwards to patches :)
> I'm volunteering to do the grunt work for 1. I think I know someone
> who might volunteer for #2 (*nudge*). And, #3 shouldn't be terribly
> hard to accomplish as long as we keep the pool API the same. If we
> want to tweak the pool API, then that's far more involved.
>
> Thoughts? -- justin
Yup, time to move forwards.