This is the mail archive of the
guile@sourceware.cygnus.com
mailing list for the Guile project.
Re: Making GC aware of overall allocation?
Lars Arvestad <arve@nada.kth.se> writes:
> Miroslav Silovic writes:
> MS> Use scm_must_malloc instead of malloc in your C code. Make sure that
> MS> the free function for your smobs returns the accurate value for the
> MS> memory freed (i.e. matching the ammount allocated with
> MS> scm_must_malloc), otherwise your gc will get very confused.
>
> But this seems to be the wrong approach IMHO. If I get my hands on a
> library that I want to access from Guile, I should not have to rewrite
> important parts of it.
well, in that case you want a plug-compatible malloc replacement to
do the bookkeeping.
I don't think you can have smart things happenning in the allocator
without touching the allocator.
or do I misunderstand the problem?
> In my case, I want to eventually distribute a C library to be linked
> in any application and do not want any dependencies on Guile. I could provide my own version of
> scm_must_malloc which would essentially be an alias for malloc(), but
> this will in the end evolve bugs with other programmers not honoring
> the Guile legacy for instance.
sorry, I don't understand this paragraph ;(
> Remember that The Competition uses ref. counting and does not suffer
> from this problem.
if you don't use GC, you don't suffer from its problems. fair enough.
do you not need the GC, then? GC and reference counting schemes can
coexist.
> There are other issues with that approach of
> course, which is shy away from, but it is not like there is not
> complexity enough already for the new and naive Guile programmer to
> instead consider the more simplistic competition.
fsck the competition, then, if it forces you to do unclean things. but
then, I don't own any FSF shares, so it's easy for me to say ;).
> Lars
--mike, ranting.
--
newsgroup volume is a measure of discontent. -- Erik Naggum