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


23-Jul-00 16:42 you wrote:
>>>>>> "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.

Not at all. You are thinking about program where guile is integral part.
I'm thinking about something like mod_guile. Apache MUST be non-gc-aware.
mod_guile is (obviously).

> I thought the whole point of this excercise is to make sure applications
> are not GC aware.

1. Application, not extension module.
2. There are NO perfect solution but with Boehm's GC you need MUCH less
GC-awareness in program.

    >>> 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.

How so ?

> 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.

Incorrectly ? What's exactlt "malloc not used correctly" ?

>     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.

The point is that THIS restriction is ALWAYS there: you MUST free varible
from shared memory with different free (mm_free), you MUCH free variable
allocated with new[] via delete[] and not with plain delete (with C++),
memory allocated by fopen can be freed ONLY with fclose and so on, if
you created image with ImageCreateFromGif then you can not destroy it with
fclose or free - you must use ImageFree: it's mere fact of life for most
languages (for all languages without GC to some extent). And this requirement
is ALWAYS there. With ANY GC. Your requirement to "protect" global varible
is VERY strage for newbie: "Protect ? Protect from WHAT ? It's in global
variable - how the heck it can disappear ?". So I NOT traded anything,
I just removed one error-prone requirement but not removed other one.
To remove this one you need to rewrite all libraries (even if you'll replace
malloc with GC_malloc or GC_malloc_atomic you STILL MUST call fclose in
right moment :-) and it's not feasible... This discussion looks like
"Let's replace manual gear with automatic one - it's easier to use for newbie"
"What's the point: newbie STILL need to know how to use accelerator"
"Huh?"
No go and ask users what he want most: system with manual gear or with
automatic one. BTW system with manual gear is FASTER - professionals using it.



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