Re: GObject and Gtk+ Finalization

[George <jirka 5z com>]

On Sun, Sep 24, 2000 at 11:41:36AM -0400, Havoc Pennington wrote:
> > As far as I can tell, a non-sunk object acts the same as long as you never
> > call _sink on it.  That is, if the user code doesn't call sink you aren't
> > changing semantics on the conversion.  An unref of an object with a floating
> > refcount still seems to unref the object correctly.  The fact that the object
> > is sunk or not doesn't seem to enter into it.
> 
> The following is OK with a floating object:
>   Object *o = object_new ();
>   pass_object_to_owner (o); /* does ref/sink */
> 
> with a nonfloating object, you have to do this:
>   Object *o = object_new ();
>   pass_object_to_owner (o); /* does ref */
>   object_unref (o);
>  
> If this isn't what your code looks like, then your code was broken,
> either the user code or the library.

The important thing is to make sure that the owner does not sink.  Not that
the object is sunk.  You can do the second version even if sink is never
called on the object.

> > I would say that this is a hack though (setting data with a destroy
> > notifier).  This is a common enough thing that there should be a more
> > "nonhackish" way to do it.
> 
> We could add a simple wrapper around doing this similar to
> gtk_object_weakref().
>  
> One disadvantage is that this destroy notify is called after the
> object is mostly finalized (except for the GObject base class part). 
> So notification of shutdown is likely more interesting than
> notification of finalize.

Well really this is what the destroy signal is as it's called from shutdown.

> This rule is required, or holding a refcount is not useful. Objects
> must be safe to touch as long as you have a reference. In practice yes
> only certain operations have to be safe (unref, checking whether it's
> destroyed, get/set object data, etc.) so that's why we get away with
> broken objects.

Yes, usable that far is ok.  I think mostly it should be for others to
unref the object safely even after being destroyed.

not all get/set will work as some stuff is references which should be
relinquished at destroy time.  I think freeing most data at destroy time
should be OK as well, as long as it doesn't make things crash, but just not
work.

> I'd be interested in Tim's full rationale for leaving it out.

AOL

George

-- 
George <jirka 5z com>
   How shall we fuck off, o Lord?
                       -- Monty Python