Hi,
Looking at apr's 1.3.x branch:
In r817810 a change to the hash table implementation was introduced, which
moves the data of a hash table from the main pool to a subpool (as seen from
the pool passed to apr_hash_make). This makes the contents of the hashtable
unavailable
On 07.01.2010 16:12, Bert Huijben wrote:
Hi,
Looking at apr's 1.3.x branch:
In r817810 a change to the hash table implementation was introduced, which
moves the data of a hash table from the main pool to a subpool (as seen from
the pool passed to apr_hash_make).
On Thu, Jan 7, 2010 at 7:26 AM, Ruediger Pluem rpl...@apache.org wrote:
This sounds like a valid point.
Yup. My fault -- sorry!
I would propose to revert r817810 / r817809 (for 1.3.x / 1.4.x) and only
keep r817806 (trunk). Graham?
IMHO we can backport this again later if the problem is
On Thu, 2010-01-07 at 16:26 +0100, Ruediger Pluem wrote:
This sounds like a valid point.
+1
I would propose to revert r817810 / r817809 (for 1.3.x / 1.4.x) and
only keep r817806 (trunk). Graham?
IMHO we can backport this again later if the problem is sorted out in
trunk.
I think we should
On Thu, 2010-01-07 at 11:00 -0800, Neil Conway wrote:
Well, the suggested fix of using a sibling pool to the hash table's
pool would work, I think -- I'd be happy to prepare patches to
implement that.
What would you hang the destruction of the array_pool against? The
parent pool? If so, we
On Fri, 2010-01-08 at 11:15 +1100, Bojan Smojver wrote:
Why can't we just use malloc() for this and hang a cleanup off the
pool? It would use less memory anyway than having another pool for
this.
Quick and dirty example of what I mean here.
--
Bojan
Index: tables/apr_hash.c
On Fri, 2010-01-08 at 11:35 +1100, Bojan Smojver wrote:
+ mem = calloc(max + 1, sizeof(*ht-array));
+ apr_pool_cleanup_register(ht-pool, mem,
+ array_cleanup,apr_pool_cleanup_null);
No, I don't think that's going to work. Again, memory may vanish before
another
On Fri, 2010-01-08 at 11:39 +1100, Bojan Smojver wrote:
No, I don't think that's going to work. Again, memory may vanish
before another cleanup runs.
Essentially, this reduces is to the problem of a sibling pool, for which
the cleanup is hanging off the pool, but with lower memory use. Still no
