Re: [gtk-list] Re: Reference counting

[Marius Vollmer <mvo zagadka ping de>]

Owen Taylor <owt1@cornell.edu> writes:

> Patrice Fortier <Patrice.Fortier@aquarel.fr> writes:
> 
> > As a gtk new user, I'd like to find some doc about this ref description
> > to understand what are the differences between: how it is, and your
> > modifications.
> > Is there any doc somewhere? except the source code I mean :).
> 
> No, the source code (and mailing list archives) are the only
> documentation you'll find. But I wouldn't worry about it much.

Yeah, right.  The patch contains a somewhat detailed ChangeLog entry.

> Before Marius's work there was no consistent scheme for reference
> counting.

Indeed.  Refrence counting is fundamentally simple.  You have to be
very careful all over the place, but the rules are simple.

I think, this is not currently the case with the reference counting in
Gtk.  It seems to be have been added whenever the explicit
creation/destruction of resources became inadequate, but not always
successfully.

[I realize that I begin to sound mildly inflamatory.  Please forgive me.
 I just begin to be able to type again after slightly breaking my
 left hand.  I just feel like writing something.  Maybe one or the
 other can benefit from it.]

Some fundamental things that might help you to get the hang of the
things I want to change:

It's all about resource management, specifically memory.  Gtk makes
use of a multitude of objects that all need their memory allocated
and freed in a proper way.

Deciding when to allocate memory is not difficult.  Deciding when to
free it is.

We have to make sure that the memory of a certain object is only freed
when we can guarantee that nobody will ever access the object again.

The easiest approach is to never ever actually free any memory.  This
is certainly safe, but of course unacceptable for long running
applications.

The next thing might be to only provide a function that can free an
object.  It is left to the user (the application programmer, say) to
explicitely destroy the objects.  Of course, this only helps for the
most `uninteresting' programs.  Opponents of automatic garbage
collectors think that they can handle all resource management problems
just fine with explicit destruction, but they effectively implement
their own automatic GC in the process without admitting it.

Now, the next best thing would be reference counting. _Instead_of_
_explicit_destruction_.  With this method, each `user' of an object is
counted in the object itself.  The users explicitely announce their
interest and loss of interest by calling certain functions.  The
memory is freed when the count of interested users (the reference
count) drops to zero.  Thus, the memory is freed as early as possible.

But reference counting breaks down when there is a cycle among the
references.  I think there are variants of ref counting that can work
with cycles but I expect them to lose the conceptual simplicity of
`pure' ref counting.  [I'll skip `weak refs' for brevity.]

Furthermore, keeping accurately track of all the tangled references
requires much attention from the programmer.

Therefore, we move on to fully automatic garbage collection.  Such a
GC does not require the programmer to manually keep track of all
`important' references but does all the magic behind his back.  Guile
has such a garbage collector, for example, and all the other
high-level languages have probably something equivalent.


As different as these techniques might be, they all address the same
problem: memory management.  Thus, we should try to step back and try
to design our objects in a way that they can work with most (if not
all) of these techniques.

For example, the freeing of the memory can happen very asynchronously
to the rest of the programs actions.  It might be useful to get some
notification when it happens, but it is not useful to then take
serious `user level' actions.  A rule like "the file is saved when the
memory of this widget is returned to the free pool" doesn't sound
right to me.  Less drastic, but equally wrong is that XWindow
destruction and widget memory mangement are so closely tied together.

Another conclusion we might draw: It doesn't make sense to provide
*both* reference counting *and* explicit freeing routines.

The complicated rules about GtkWidgets and their `floating' flag are
there to avoid breaking *all* existing code.

> The original setup worked pretty well for the simple cases in C, but
> not otherwise.

Hmm, I'm not sure, but I think there are already memory leaks with C.
Some GtkAdjustments are never really freed I think.