Re: [gtk-list] Re: Tracking object deletion

[Kenneth Albanowski <kjahds kjahds com>]

On 12 Dec 1997, Owen Taylor wrote:

> 
> Kenneth Albanowski <kjahds@kjahds.com> writes:
> 
> > On 11 Dec 1997, Owen Taylor wrote:
> > 
> > > But I still think that [keeping a refererence count, and making Gtk
> > > functions fail silently] better [than the deletion callback]- when
>               ^^^^^^^^^^^^^
> In the special case where the user has stored a reference to a window
> independently of a widget, and that window is destroyed by external
> forces. Not in general.

Right, we can assume that normal "stick a button into a window and then
forget about it" code just does everything right and unsurprisingly, by
default.

> Read Marius's proposal. (If desired, I could repost it.) Essentially,
> the idea is that an object has an extra reference and a "floating" flag
> until it is added to a parent for the first time. (Toplevels have
> a virtual parent) After that, the widget heirarchy reference counts
> in the normal manner.

This probably could be considered as a variant on the theme of a "weak
reference".

> Which means that:
> 
>   b = gtk_button_new_with_label ("Add sheep");
>   b = NULL;
> 
> is a memory leak (no surprise). To keep 
> 
>   $b = new Gtk::Button "Add sheep";
>   $b = undef
> 
> >From being a memory leak, a language binding would internally in
> the new() method doing something like.
> 
>   widget->gtk_widget = gtk_button_new();
>   gtk_widget_ref (widget->gtk_widget);
>   gtk_widget_sink (widget->gtk_widget); // Clear "floating" flag and
>                                         // extra ref

It almost sounds like we are simply saying that widgets start out with
zero references, but don't destroy themselves until they are decremented
to zero. 

> Cool. Though I hope people will still try to write the more basic
> widgets in C so they can be used from all languages.

Actually, that's another important point. There's no reason that a widget
written in Perl can't be used by other languages (Gtk's widget mechanism
sees to that), assuming that the other language can be running at the same
time.

About the only thing I see that is stopping this is the current
gtk_signal_set_funcs() call, which would completely disrupt any other
active Gtk users. If that is removed completely, then I think we should be
able to write widgets in both C and Perl (assuming Perl has been
embedded), and call them from either.

Not that Perl widgets are going to be as fast or convenient as Gtk
widgets, but that the technology exists at all is a strong step forward.
Java or Guile widgets might be very popular.

> A third possibility is to separate out the Perl shadow object from
> the object the user deals with. i.e.
> 
> 3) for any GTK widget, implemented in Perl or not, there is a Perl
>    object that refers to the GTK widget, but is not referred to by
>    the GTK widget. For widgets implemented in Perl, there is a shadow 
>    object that is referred to by the GTK widget but does not refer
>    to the Perl widget. (If desired a shadow object could also be kept
>    for non-Perl widgets). The user object is destroyed when the last 
>    Perl object is destroyed, and recreated if necessary. 

Ah, yes, that is a good point. 

> I suppose 2) really just combines the two objects into a single
> object that serves both purposes. (Since user object => shadow
> object, there is no real need for a separate user object) But
> I don't quite see how you are going to figure out when an object
> really should be destroyed. As long as the Perl object holds
> a reference to the GTK object, it will never be destroyed, So you'd
> have to unref() the GTK object when the Perl reference count
> drops to 1. (You have to keep an extra reference count around,
> or it will be destroyed.) The only way I can think of implementing
> this uses an auxiliary object anyways...

Yes, you're absolutely right. Obviously I shouldn't write about reference
counting on too little sleep.

The dual mechanism looks good, though it prevent the Perl interface from
being as elegant. You can add data to the shadow object, but it only
persists as long as the particular reference exists. Data added to a
genuine Perl/Gtk object is permanent, but you need to go through an extra
step to access it. Well, if that is required, so be it.

Note that we could use set_data for this, if we had deletion callbacks on
data, or object... :-)

Actually, the main headache I have right now is signal implementation.
Basically, it's not much fun trying to muck about with Gtk class/object
definitions from XSUB code, especially as object sizes cannot be directly
retrieved.

> So if the application writer wants the window to stick around, he
> installs a handler that returns TRUE. If he wants the object to
> stick around, he keeps an extra reference to it.

_Or_, calls hide() instead of unref(), just to confuse matters.

> 1) I'm not completely sure this is necessary. I think it should be
> sufficient to:
>   a) reference count
>   b) Proved deletetion hooks for all forms of arbitrary data 
> 
> (This excludes one thing - allowing language objects to last longer
>  than GTK objects - but I think as long as long as GTK objects can
>  be kept around without keeping X windows around this is OK. In any
>  case, for GtkObjects, I think the "destroy" hook will be what you
>  are looking for. In Marius's proposal, a handler for "destroy" by
>  definition can't do anything constructive with the object.)

Yes, this sounds good enough.

> Well, remote objects may well be destroyed for no apparent reason. (Power
> failure, etc) A keep-alive is a way of doing sanity checks on
> the reference count. If a surrogate doesn't respond to a callback,
> then it just like the reference count had been decremented. CORBA
> leaves such things to the interface writer, however.

Exactly. Gtk is in a position to define part of the interface, if it has
to.

> I wasn't saying that the "destroy" signal would be removed. I was
> just saying that in the simplest possible way of implementing Perl
> objects, it wouldn't be needed. For more complicated methods of
> doing things, it might be.

Indeed.

> 
> > For example, I just realized that gtk_object_set_data() could work in
> > exactly the manner I need, _if_ there was a callback that could be invoked
> > when the data was cleared, due to object destruction. The most basic point
> > is I need _some_ way to tell all Gtk objects, even ones not descended from
> > a Perl class, that they need to tell Perl about their disappearence.
> 
> This is probably a good idea, in any case. Generally, I think that
> any possible way of storing arbitrary data into a GTK structure should
> have an associated destruction callback.

Yes, and there are numerous places (strings, especially) where this is
unclear, or not considered. Think about the really interesting issue of
_de_registering widgets...

-- 
Kenneth Albanowski (kjahds@kjahds.com, CIS: 70705,126)