This is the mail archive of the
guile@sources.redhat.com
mailing list for the Guile project.
Re: Again: Guile + Boehm's gc
>>>>> "Khimenko" == Khimenko Victor <guile@khim.sch57.msk.ru> writes:
>> I have a slightly different take on using Boehm's GC in guile.
>> As far as I can see, if the goal is to make Guile's GC
>> transparent to the application it will be necessary to replace
>> malloc with Boehm's malloc.
Khimenko> No. You can use your standard system malloc and Boehm's
Khimenko> GC.
Only if you don't mind your programs being GC aware. I thought the
whole point of this excercise is to make sure applications are not GC
aware.
>> That's a pretty intrusive requirement. For instance, what
>> happens if I want to use tools like electric-fence or ccmalloc
>> (malloc debuggers) to look for dangling pointers.
Khimenko> Just use them.
I have. I wasn't making an idle speculation. Mixing malloc and
GC_malloc is a recipe for memory leaks. Consider the case of a user
smob. You need to use GC_malloc on top of the current smob system,
and you need to make sure that malloc isn't used incorrectly.
Khimenko> The only rule is to NOT use free for memory
Khimenko> obtained via normal malloc (pretty obvious: free from
Khimenko> system library will not know what to do with object
Khimenko> allocated with GC_malloc).
This is exactly the point about "special rules". You've traded a
system where you must remember not to place certain opaque types into
a global variable for a system where you have to remember which
pointers are malloced by which routine. If you use the wrong free, it
creates a bug that is *extremely* difficult to track down.
Cheers,
Clark