Re: tooltips and refcounts

[George <jirka 5z com>]

On Thu, Sep 03, 1998 at 05:17:14AM +0200, Tim Janik wrote:
> > But, the point George is trying to make is that the application
> > writer does not want to know that the tooltips is keeping
> > around a pointer to the tooltips. 
> 
> as i stated in an even older mail on this subject, the *actuall* ref count
> is not of the application writers bussiness. whether its the widgets tooltip
> or GLE or an interpreter or some gtk internal code, e.g. a long lasting
> timeout, who's holding a pending refcount on an object is really of no
> interest to an application. that's because ref_counts only care about the
> widget's memory allocation and should have nothing to do with their
> actuall on-screen appearance. that's why containers destroy widgets
> explicitely upon their destruction and don't just decrement a refcount.

well I see this as pretty bad especially for bindings of things that
use GC ...

scenario ... if you use a GC, you don't destroy an object if there is
a refcount to that object, right? ... ok ... tooltips remove themselves
automatically when the object is destroyed (therefore they don't care if
the object is destroyed, there is nothing that makes them want to hold
on to that object)

I see that as an endless circle ... the object won't get destroyed until
it's refcount is 0 and tooltips wait for the object to be destroyed ...

refcount doesn't seem to be of any use in this case ... refcount would
be of use if you want to make sure that the object doesn't dissapear
under you ... using refcounts in references where you actually don't care
make things harder ...

for a GC it would be quite hard to distinguish what is a refcount that
can be ignored and what it can't ...

a bindings should be able to just _remove the widget and forget about it
... if the widget is referenced somewhere else (somewhere where we care
about it) it won't get destroyed ... if not it will ....

however if at any time the user has set a tooltip ... the tooltip will
keep the widget alive ad infinitum ... causing a leak

if somebody writing such bindings wants to avoid that he must keep a
record (refcount) of relevant refcounts .. and this defeats the purpose

> this assumption is false, refcounting.txt describes this in a detailed
> manner, refcounting cares about the finalization stage of an object, it
> just happens that this implies the explicit destruction as well, which
> is why a not yet destroyed object gets destroyed when the last refcount
> drops.
> if you want a widget to "go away", i.e. take visual action on screen,
> you have to gtk_widget_destroy() it.

this is not about "visual action on screen", this is about memory ...
the widget already went away .. however it stays in memory because the
tooltip holds a refcount ...

the application writer has to now figure out by himself if he should
destroy the widget by hand or if he will need it somewhere else ...
clearly, gtk should take care of that ...

> you are right that the tooltip's ref count on widgets is redundant, but
> even though it may short-time-cure the panels problems, that's just fighting
> symptoms. if the panel relies on certain refcounts, that behaviour is
> _conceptually_ wrong. maybe its currently just the tooltips that cause
> this assumption to fail, but you can soon encounter different problems
> wrt refcounting with such behaviour, e.g. if you use GLE or if we someday
> decide to implement some kind of global GC for gtk.

the panel relies not on certain refcounts ... but on the fact that when I
remove it from the last container (not by destryoing the container, but by
using remove) ... that it will go away in terms of memory usage ... if gtk
for whatever reason still needs it around after that, it can increase the
refcount and keep it that way ... if gtk holds references which do not care,
it should bind the destroy signal to a cleanup routine and not increase the
refcount

increasing refcounts for cases where we bind a cleanup routine or in places
where we should bind a cleanup routine ... makes it really hard to decide
wheather the widget should be dumped from memory or not and it pushes that
decision to the application writer ... meaning refcounts are of no use to the
app writer suddenly

> so the baseline is, if you want a widget to disappear: destroy it, unparentation
> will immediatedly be taken care off, memory deallocation is handled at
> finalization stage which might get delayd for reasons not apparent to the
> application/programmer.

what if I hold a refcount somewhere in my app to that widget ... somewhere
where I can't bind a cleanup routine ... where I need the widget to stay
around (say I have some data hanging on the widget and I can't destroy it
yet) .... but I don't know that at the time when I want to _remove it from
it's parent and it to disappear from screen ...

had refcounts worked as described above ... I could just do a _remove
and if all places had unreffed it (including my own refcount) then it would
go away ... if not, it would hang around in memory until I unreffed it
(after getting the data I want)

the current scheme makes _ref/_unref unusable to the app programmer as they
have to keep their own refcount if they want to do refcounting ... bad bad
bad

George

-- 
------------------------------------------------------------------------------
George Lebl <jirka@5z.com> http://www.5z.com/jirka/
------------------------------------------------------------------------------
  The following implements RSA in perl and is illegal to export from the US:

          #!/bin/perl -sp0777i<X+d*lMLa^*lN%0]dsXx++lMlN/dsM0<j]dsj
          $/=unpack('H*',$_);$_=`echo 16dio\U$k"SK$/SM$n\EsN0p[lN*1
          lK[d2%Sa2/d0$^Ixp"|dc`;s/\W//g;$_=pack('H*',/((..)*)$/)