This is the mail archive of the guile@sources.redhat.com mailing list for the Guile project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

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

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]