Re: [gtk-list] Re: GC and GTK+

[Ulric Eriksson <ulric edu stockholm se>]

On 20 Apr 1998, Owen Taylor wrote:

> Ulric Eriksson <ulric@edu.stockholm.se> writes:
> 
> > On Sun, 19 Apr 1998, Owen Taylor wrote:
> >
> > > - Does GC solve multi-language memory management problems?
> > >
> > > Not unless the same GC system is used for all languages. A cycle
> > > that traverses two languages cannot be found unless the garbage
> > > collector can walk the heap in both systems.
> >
> > Certainly one can have different GC systems for different languages,
> > otherwise the problem becomes almost unsolvable (what will be rewritten to
> > fit the 'there can be only one' system).
> >
> > In SIAG, SIOD and Guile (and Tcl) coexist nicely, each doing its own GC.
> > Gtk should handle its own resource management and do it well, anything
> > more is probably too much.
> 
> The problem is that GTK's situation is much more complicated
> than something like SIAG.

If it is allowed to be, yes. The reason it's simple in SIAG is that
nothing is ever affected by GC in more than one language. Anything that
is needed in more than one place is copied.

The other way to prevent GC in one language from corrupting data in
another is to tell the collector not to collect it, but then we are back
to manual management.

> In many circumstances when mixing languages, you are only
> using objects form one language in another. With GTK objects
> the ability to attach callbacks means that GTK objects
> used in a language become part of the languages memory
> management system.

Again, if they are allowed to. In Gtk, I can do things like

        GTK_SGRID(w->ui->grid)->visible_cursor = TRUE;

which is gross, IMHO.

BTW, note that I wrote "resource management". GC of colours, pixmaps and
fonts would be as useful as GC of memory, possibly more.

Ulric