Re: [gtk-list] Re: GtkObject ref counting [was: resize queuing]

[Marius Vollmer <mvo zagadka ping de>]

Kenneth Albanowski <kjahds@kjahds.com> writes:
>
> As far as I can tell, this suffers from the same problem as the current
> system: if a reference is kept by an external environment, the widget can
> never be destroyed.

Hmm, we could start by defining what "destroying" means and when the
destroy signal is emitted.

I think "destroying" should be the act of completely erasing the
existence of the object.  The "destroy" signal is emitted, the object
draws its last breath and the memory is reused for something
different.  This can only happen when nobody is using this object any
longer.  To ensure this, we keep a reference count.  There is no
explicit destroy request; the object is implicitly destroyed when the
reference count drops to zero.

All widgets should hold a reference (that is reflected in the
reference count of the referenced object) to their children.  When a
parent is destroyed (because its reference count drops to zero, there
is no other reason), it releases the references to its children.  When
their reference count drops to zero due to this, they are likewise
destroyed.

Programmers must be aware that removing a widget from its parent can
implicitly destroy it.  But when they want to keep it, they have to
count their references, of course.

I think that when we want to have reference counting on objects (and I
think we should), this ref counting should be the *only* mechanism to
control the lifetime of an object.  The hard part about getting ref
counting right is that you have to obey everywhere, all the time.  We
should not complicate their simple semantics with funny exceptions.

Ok, I couldn't precisely name what I think is wrong with the current
implementation, but I think ref counting is something fundamentally
simple and I have difficulties figuring out the interaction between
the destroy request (gtk_object_destroy) and ref counting.