[PATCH] avoid GC segfault/hang/etc: make gnulib's hash module use GC

Jim Meyering jim at meyering.net
Mon Aug 1 18:35:39 UTC 2011


Pete Zaitcev wrote:

> On Mon, 01 Aug 2011 17:54:48 +0200
> Jim Meyering <jim at meyering.net> wrote:
>
>> As for your additional fix, please retain the GC_gcollect-calling
>> code one way or another -- at the very least #ifdef'd out.  What do
>> you think about leaving it enabled?  Does it impose a significant
>> performance hit?
>
> I haven't measured the performance. Also, if I were to keep this
> call around, then I ought to find a thread-safe way to do it.
> I'll think about it.
>
>> Re your own list code, please use what you put in that patch,
>> at least for now.  Simpler is better, especially for a bug-fixing change.
>
> Yeah, maybe... Actually I'm thinking maybe just use <queue.h>. It existed
> for a while.

The advantage of using your hand-rolled list code
is that its memory allocation is already GC-enabled.
If you use queue.h, then we'll have to hack queue.c like I did
for hash.c, so that its malloc-like calls get mapped to their
GC analogs.

>> +++ b/rest.c
>> @@ -864,15 +864,12 @@ destroy_state_postprocessor (void *ms_v, void *client_data)
>>  	my_state *ms = ms_v;
>>  	if (ms->post)
>>  		MHD_destroy_post_processor (ms->post);
>> -	if (ms->dict)
>> -		hash_free (ms->dict);
>>  }
>
> I ack this too.

Thanks.


More information about the iwhd-devel mailing list