Re: [gtk-list] Re: Proxy objects and circular garbage

[Michael Beach <mbeach zip com au>]

Vollmer Marius wrote:
> 
> Michael Beach <mbeach@zip.com.au> writes:
> 
> > So, my question is, how do people get around/deal with this sort of
> > thing in other language bindings, such as Perl, Python, Eiffel and
> > Guile?
> 
> In the guile-gtk bindings, the gtk->proxy link is a weak one.  More
> precisely, the pointer is stored in a place where the conservative
> collector of Guile does not find it.  I think this works fine.
> 

So you are ok about the proxy getting GCed, even if the gtk+ object it
proxies for is still live?

> However, there are other situations that creates a real circle that
> cannot be broken by weakening one link.  One such situation arises
> with signal handlers.  When you connect a Scheme procedure as a signal
> handler to a GtkObject, that connection must prevent the Scheme
> procedure from being collected.  But more often than not, the Scheme
> handler has the GtkObject in its environment, thus forming a circle.
> 
> This dilemma gets resolved because when you "destroy" an GtkObject,
> all its signal handlers are disconnected.  "Destroying" is not at all
> related to memory management, it merely makes the object unsuable, by
> removing it from the Screen when it's an widget, for example.  Thus, a
> positive reference count will not prevent a GtkObject from being
> destroyed.
> 

I had a suspicion that there would be a problem with signal handlers,
but it sounds like it works itself out. Good.

> A similar circle will arise when attaching Scheme values to an
> GtkObject with gtk_object_set_data/gtk_object_get_data but I don't
> think that it is always the right thing to detach these datas upon a
> "destroy" request.  Fortunately, Guile has other means to attach
> arbitrary key/value pairs to objects and we should use these instead.
> 

So are you saying that the data attached in this fashion is dropped by
the gtk+ object when it is destroyed? Lucky you mentioned that, as I
hadn't considered it.

But when you say there are other ways of attaching key/value pairs to
objects, I assume you are talking about attaching these to the proxy
object? However wouldn't there be a problem with this, in that the gtk+
object only maintains a weak link to the proxy, and so the proxy (and
associated key/value pairs) could go away if all other refs were lost?

This was the big problem I anticipated with the weak-link-to-proxy
solution (which I am currently about to implement anyway). So if you
consider that a proxy has three potential uses :

1) tests for object identity
2) "handle" for use in function calls
3) storing application state associated with the object

then number (3) is out of the question.

Regards
M.Beach