Re: GObject and Gtk+ Finalization

George <jirka 5z com> writes:
> On Mon, Sep 25, 2000 at 09:04:21AM -0400, Havoc Pennington wrote:
> > You just removed the count owned by pass_object_to_owner(). The
> > floating count remains, but can be removed at any time.
> Yes, with an unref

No you can't remove the floating count with unref. Period. Those are
the rules dude. ;-)
> Anyway, I think we are talking on different levels.  You are saying do a
> ref/sink in init to make sure that simple refcounting only is used.  Thus
> anything that uses sink on it will be wrong and buggy.

Nope, sink() is still correct; it will just be a no-op. This means
that no one ever gets an implicit refcount, only an owned refcount.

If object_new is as follows:

object_new ()
  o = type_new ();
  o->ref ();
  o->sink ();

  return o;
Then we return a reference count which is OWNED BY THE CALLER of
object_new (). If we do the usual GtkObject thing, we return a
floating reference which is NOT OWNED BY THE CALLER. Which means that
in the first case the caller must call unref(), and in the second the
caller must not call unref().

I am saying, do the ref/sink, then document that object_new() returns
a ref to the caller.

> I say, screw that, I just use simple refcounting and ignore the floating
> flag.

You can't do that, because you have to know whether you own a
reference from object_new().
> Either way, code that uses sink is buggy and won't work right (either leak or
> unref one too many times).

Nope. ;-) The two examples I presented earlier both work
right. _Anyone_ can call sink() any number of times and things
work. Anyone can remove a reference they own and things work. If
people remove refs they don't own, things break.

> But regardless, the argument is moot since both ways work.  The reason for my
> argument was not saying that doing a ref/sink in init is bad, but that it's
> not neccessary functinally, and I thought you said that it is.  Wheather it's
> cleaner or less prone to user code bugs is a different story.

The argument is _not_ moot at all, it's very important to get this
right or you get memory bugs everywhere.

The reason you have to do ref/sink in init for something that will
become a GObject is that a future GObject will return a reference from
object_new() that will be owned by the caller, and if you don't
ref/sink then your object_new() will not return such a reference.
> Well, the refcount rules I see are the code.  And that's what it says.
> Actually from what I can see, just about 90% of all non-widget GtkObjects in
> different GNOME things are NEVER sunk, yet their refcounting is still ok.

If the code is the whole interface, I guess g_free (0x357329)
and gtk_label_new (0x1) and that type of thing should work fine. ;-)


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]