You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@apr.apache.org by Max Bowsher <ma...@ukf.net> on 2005/01/16 15:09:31 UTC
Please merge r59141 (Berkeley DB 4.3 support) to apr 0.9.x
Please merge r59141 (Berkeley DB 4.3 support) to apr 0.9.x
The diff applies cleanly (with the exception of the CHANGES file, of
course).
Once this is done, please could an apr-util 0.9.6 release be considered.
Thankyou,
Max.
Re: Please merge r59141 (Berkeley DB 4.3 support) to apr-util 0.9.x
Posted by Max Bowsher <ma...@ukf.net>.
Graham Leggett wrote:
> Max Bowsher wrote:
>
>> Please merge r59141 (Berkeley DB 4.3 support) to apr 0.9.x
Oops, I mean apr-*util*.
>
>> The diff applies cleanly (with the exception of the CHANGES file, of
>> course).
>
>> Once this is done, please could an apr-util 0.9.6 release be considered.
>
> Could you also create patches for APR v1.0 and trunk (if possible)? -
> it's possible that a release for both 0.9 and 1.0 will be made at the
> same time.
I think you may have misread my mail. I asked for a merge of a feature to
the 0.9.x branch - it's already present in 1.0.1 and trunk.
Max.
Re: Please merge r59141 (Berkeley DB 4.3 support) to apr 0.9.x
Posted by Graham Leggett <mi...@sharp.fm>.
Max Bowsher wrote:
> Please merge r59141 (Berkeley DB 4.3 support) to apr 0.9.x
> The diff applies cleanly (with the exception of the CHANGES file, of
> course).
> Once this is done, please could an apr-util 0.9.6 release be considered.
Could you also create patches for APR v1.0 and trunk (if possible)? -
it's possible that a release for both 0.9 and 1.0 will be made at the
same time.
Regards,
Graham
--
Re: Inf. on pool...
Posted by Graham Leggett <mi...@sharp.fm>.
Nick Kew said:
> Tying it to memory only is underselling it. Pools are about resource
> management, memory being just one of the resources in question.
True, but sometimes an explanation that covers too much material can be
too confusing.
Regards,
Graham
--
Re: Inf. on pool...
Posted by Nick Kew <ni...@webthing.com>.
Graham Leggett wrote:
> Eufordia wrote:
>
>> Is there a good soul that could explain me what is exactly a "pool"?
>
>
> Traditional ways of asking for memory involves:
[chop]
Tying it to memory only is underselling it. Pools are about resource
management, memory being just one of the resources in question.
I already pointed him to http://www.apachetutor.org/dev/pools
but my reply didn't go to the list (faffing about with unfamiliar mailer:-)
--
Nick Kew
Re: Inf. on pool...
Posted by Eufordia <eu...@tiscali.it>.
Thank you very much!!
>
> Hope this gives you a direction to start in.
>
> Regards,
> Graham
> --
>
Re: Inf. on pool...
Posted by Graham Leggett <mi...@sharp.fm>.
Eufordia wrote:
> Is there a good soul that could explain me what is exactly a "pool"?
Traditional ways of asking for memory involves:
- asking for some memory
- giving it back when you are finished
The trouble is with the second part - how are you sure you gave all the
memory back when you were finished with it? Usually no, and thus we have
memory leaks.
What if you could do this:
- ask for some memory
- ask for some more memory
- ask for even more memory
- ok I'm finished - clean up all the above in one go
If you could, you could free everything up in one go, and be sure you
didn't miss anything, and be sure again that you're not leaking memory.
APR allows you to do this by using "pools" of memory. Depending on the
task you are trying to do, you do this:
- create a pool
- allocate memory from the pool
- allocate more memory from the pool
- and more and more
- ok, I'm done - clean up the entire pool in one go
To make it more fun, when you create a pool, you can create it as a
"child" of another pool. For example, you might have a "global" pool
that all your memory is taken from. Then you create a "subtask" pool as
a child of the "global" pool to perform some task. When you're finished
doing the subtask, you clean up the subtask pool. If an error happens
and you have to exit completely, if you clean up the global pool, the
subtask pool will be cleaned up too.
The fun continues: You can get the pool cleanup to clean up more than
just memory. If you open a file, register a function to close the file
with the pool. When you clean up the pool, the file will be closed, and
you don't leak file descriptors.
APR pools make it easy and clean for code to make sure it cleans up
after itself preventing leaks.
Hope this gives you a direction to start in.
Regards,
Graham
--
Inf. on pool...
Posted by Eufordia <eu...@tiscali.it>.
Hi,
I'm a student and I have to use the apr library for a little work.
My problem is the documentation.
Is there a good soul that could explain me what is exactly a "pool"?
thank you
Luca
Re: Please merge r59141 (Berkeley DB 4.3 support) to apr 0.9.x
Posted by Jani Averbach <ja...@jaa.iki.fi>.
On 2005-01-16 12:29-0500, Garrett Rooney wrote:
> Max Bowsher wrote:
> >Please merge r59141 (Berkeley DB 4.3 support) to apr 0.9.x
>
> Committed in revision 125358.
Hello,
I like to let you know one small difference between 0.9.x and 1.0.x
regarding Berkeley DB, they use different kinds of lib names, when
they are seeking a BDB system.
I have pointed this out when the patch went in, but nobody commented
it: http://marc.theaimsgroup.com/?l=apr-dev&m=109595023015477&w=2
0.9.x uses following functions to find BDB:
4.1:
APU_CHECK_BERKELEY_DB("4", "1", "-1",
"$places",
"db41/db.h db4/db.h db.h",
"db-4.1 db4 db"
)
...
4.2:
APU_CHECK_BERKELEY_DB("4", "2", "-1",
"$places",
"db42/db.h db4/db.h db.h",
"db-4.2 db4 db"
)
When 1.0.x uses:
4.1:
APU_CHECK_BERKELEY_DB("4", "1", "-1",
"$places",
"db41/db.h db4/db.h db.h",
"db-4.1 db41 db4 db"
)
...
4.2:
APU_CHECK_BERKELEY_DB("4", "2", "-1",
"$places",
"db42/db.h db4/db.h db.h",
"db-4.2 db42 db4 db"
)
So now 0.9.x is using a lib name 'db4' for 4.1 and 4.2, but for 4.3 an
additional lib name 'db43' is used. If this is ok, then so be it.
BR, Jani
--
Jani Averbach
Re: Please merge r59141 (Berkeley DB 4.3 support) to apr 0.9.x
Posted by Max Bowsher <ma...@ukf.net>.
Garrett Rooney wrote:
> Max Bowsher wrote:
>> Please merge r59141 (Berkeley DB 4.3 support) to apr 0.9.x
>
> Committed in revision 125358.
Thanks!
>> Once this is done, please could an apr-util 0.9.6 release be considered.
>
> I don't see any reason 0.9.6 couldn't be released, but I don't know the
> details of what's involved in rolling a release, and I won't have the
> time to devote to it in the next week or so, so if someone else could
> step up to the plate it would be much appreciated.
I don't want to rush anyone - personally, I'm unlikely to get around to
using BDB 4.3 for about a month - I just wanted to get the process started,
in case you wanted to do a "release soon" announcement, and then wait awhile
to see if anyone came forward with additional things to include.
Thanks again,
Max.
Re: Please merge r59141 (Berkeley DB 4.3 support) to apr 0.9.x
Posted by Garrett Rooney <ro...@electricjellyfish.net>.
Max Bowsher wrote:
> Please merge r59141 (Berkeley DB 4.3 support) to apr 0.9.x
Committed in revision 125358.
> Once this is done, please could an apr-util 0.9.6 release be considered.
I don't see any reason 0.9.6 couldn't be released, but I don't know the
details of what's involved in rolling a release, and I won't have the
time to devote to it in the next week or so, so if someone else could
step up to the plate it would be much appreciated.
-garrett