Re: RFC: Reference counts on Gtk2::Tooltips

["Ross McFarland" <rwmcfa1 neces com>]

> On Mon, May 05, 2003 at 11:40:31AM -0400, muppet wrote:
> > this happens because although the tooltips object stores a pointer to
> > itself in the client widget's user data, it does not allow that pointer to
> > keep a reference.  thus, it is up to the application programmer to store a
> > reference to the tooltips object which will outlive the objects which have
> > the tooltips attached to them.
>
> Is there any chance of fixing gtk?

the gtk team would in all likelihood argue that it's not a problem/bug with
gtk, but with how people (possibly) use it.

it would perhaps be the most common practice to create tooltips as a global
var (in c and/or perl) in which case you'll never know that this issue exists.

> > in other words, it behaves as designed.
> >
> > however, that behavior is rather surprising.  also, from what i can tell
> > it is unexpected, since most C code i've seen actually leaks the tooltips
> > objects so they stay alive by accident.
>
> So if you preserve the C behavior in Perl, how could the Perl
> programmer avoid leaking tooltips?  Basically, you're saying that
> every Perl programmer that doesn't want a memory leak has to invent his own
> way of managing tooltips.  That seems like a pointless waste of effort.

preserving the c behavior will not leak tool tips they will be unrefed and
destroyed when the block in which the var was created goes out of context. in
this way perl does not have the memory leak whereas a similar c program would
have.

> > it is trivial to have the perl wrapper for set_tip keep a reference on the
> > tooltips object so that it will stay alive; my question is, since it's
> > behaving as designed, is this subversion the right thing to do?  or should
> > we simply document the behavior in a "pitfalls" or "gotchas" document?
>
> Does the C API have the hooks you would need to dereference the
> tooltips when the widget is destroyed?  If so, why not fix it?
> People expecting the C behavior would lose nothing, and people
> expecting sane semantics would not be surprised.

no, but such things could be added in the wrapper. the problem is if this was
the behavior it would have to be documented, really which ever choice is made
will need to be documented. due to perls garbage collection tips that would
have been leaked in c (where the tips would reside in leaked memory and still
work for the duration of the app) will be cleanned up and disappear. to fix
this would require a change in behavior from the c code that would have to be
documented.

> In general, documenting pitfalls is stupid.  Even in the unlikely
> case that a programmer reads it, every pitfall is something else he has to
> keep in mind.  If the problem is recognized, fix it.

i'm just saying that, if fixed or not, either the pitfall or the fix will have
to be documented.

as it currently stands the perl wrappers behave as a correctly written
(thorough memory management) c app would.

-rm