On 1/7/2010 9:12 AM, Bert Huijben wrote:
>
> 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
On 19 Jan 2010, at 12:17 AM, William A. Rowe Jr. wrote:
I'd like to roll 1.4.2 ASAP, all that we are waiting for is to roll
back
this breakage. Volunteers?
Graham, you committed r817810, any thoughts on other changes
required, besides
simply reverting the single commit?
I think revertin
On 1/7/2010 6:06 PM, Bojan Smojver wrote:
> 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
On 1/17/2010 4:57 AM, William A. Rowe Jr. wrote:
> On 1/7/2010 9:12 AM, Bert Huijben wrote:
>>
>> 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 po
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 n
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
ano
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 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 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 sh
On Thu, Jan 7, 2010 at 7:26 AM, Ruediger Pluem 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 sorted out in trunk
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_ha
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
12 matches
Mail list logo
