[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