Re: GObject reference counts

[Guillaume Cottenceau <gc mandrakesoft com>]

"muppet" <scott asofyet org> writes:

> some time ago we had a discussion on this list about the life time of perl
> wrappers for GObjects versus the lifetime of a GObject.  i don't exactly
> recall the final decision, and am not entirely certain what the current
> implementation does, but i'm bumping into it because it's different from the
> old gtk-perl.

this has been discussed but I can't find the relevant messages
from the archives :(. at least, one can look at

http://mail.gnome.org/archives/gtk-perl-list/2002-November/msg00048.html

IIRC i was defending a "perl view", e.g. having perl object
lifetime corresponding to gtk object lifetime (like in gtkperl, I
think); e.g. not necessarily calling ->destroy or ->unref, when
lexical variable holding a gtk object is collected.

It's useful to underline that it should not be easy for GObjects
not inheriting from GtkObject because functions returning some
are sometimes supposed to hold a reference on it (hence, call
->unref when destroying the object), sometimes not (hence, if you
call ->unref when destroying the object you segfault). Last time
I checked (some months ago) the .defs files supposed to document
that behaviour were not correct in the examples I looked at. Not
talking about the fact that we're not doing automatic function
wrapping, hence doing that by hand is somewhat risky, because
when taking the wrong decision means the program will segfault.

I think that Goran and Daniel (If I remember correctly, again)
were defending another view in which they wanted to stay as close
as gtk+'s behaviour in C as possible: e.g., perl object is just a
convenience wrapper: (1) destroying it has no influence on gtk
object, (2) destroyed gtk object will not unref perl object.
That's what we currently do. It has the advantage of being simple
in implementation, and not surprising people with differences
from the usual gtk+'s behaviour. For my personal use, I have to
say it annoyed me less than I thought (even if it did annoy).

E.g. in the current situation:

- people need to ->sink unused GtkObject's, ->unref allocated
  GObject's, and ->free boxed types

- once a gtk object is destroyed, don't access perl object
  anymore or it will segfault


> last night i was working on porting some stable gtk-perl code to gtk2-perl. 
> the old code did something like this [1]:

[...]

> when i ported this to gtk2-perl, the application segfaulted when trying to
> extract information from the widgets after the do_config call[2].  this means
> that the custom widgets got destroyed with the dialog, even though i still
> had scalars pointing to them in the calling code.  that in turn means that

Yes. You must never access anymore a gtk object when it has been
destroyed.

> the dialog had the only references to the widgets.  [is this not correct?]

Well that's not exactly how I see it. Perl reference holding a
gtk object is rather like a pointer allowing accesses to methods
on the gtk object than an authoritative object. If the gtk object
got destroyed behind your back (or by you calling ->destroy),
then it's no longer valid and if you make any method access on
it, you'll suffer.

> without a lot of research into the code, my intuition is that gtk-perl kept
> a reference on the object so that it stayed alive as long as the perl scalar
> referred to it, whereas gtk2-perl lost its scalar's reference to the object
> when  the container sunk the widget's floating reference.

Yes, I also think that was the case.

-- 
Guillaume Cottenceau - http://people.mandrakesoft.com/~gc/