Hey folks, Thanks for the debugging and the patch, Mark!
On Wed 01 Jun 2011 01:18, Neil Jerram <n...@ossau.uklinux.net> writes: > l...@gnu.org (Ludovic Courtès) writes: > >> Mark H Weaver <m...@netris.org> skribas: >> >>> The main reason I haven't already pushed this patch is that there is a >>> slight complication: when you register custom allocation functions for >>> use by GMP, they get used for _all_ allocation, not just for digits. In >>> particular, they get used to allocate the block returned by mpz_get_str >>> (when the first argument is NULL). This means that if the user of >>> mpz_get_str uses the standard "free" to deallocate this block, it will >>> fail badly. This could potentially affect programs which use libguile >>> but also use the GMP functions directly. >> >> Yes, that's a problem, probably even be a showstopper for 2.0. :-( >> >> What do others think? > > Provide an API to allow the trade-off to be decided by the application > developer? I think this only makes sense as an interim measure, like if we want to change GMP to allocate only via GC_malloc in 2.2, then provide the option in 2.0. There has to be a better long-term solution though. What if we get libgc to track total heap size (whether the user has malloc, g_slice_alloc, or whatever), and start doing GC more frequently if it sees the total heap size going up? Andy -- http://wingolog.org/
