Re: Proposal: gtk_object to emmit reference changed signals

["Sam O'Connor" <oconnor eiffel com>]

Thanks for your reply.

Elliot Lee wrote:
> 
> On 9 Nov 1999 21:36:24 -0500, Sam O'Connor <oconnor@eiffel.com> wrote:
> >I would like some kind of hook to do stuff
> >when an object's reference count changes.
> >I guess a signal for ref and one for unref.
> >I need to be able to do stuff when the count
> >goes from 1 to 2 and when it goes from 2 to 1.
> >
> >I am currently working on a problem that
> >involves getting the GTK+ reference counting
> >system to cooperate nicely with a mark & sweep
> >GC in an Eiffel system.
> 
> Trying to mirror refcounts between different objects didn't work very well
> for the ObjC bindings when I was doing them. I'm not quite clear on how the
> Eiffel GC works - does it allow you to have an is_object_in_use() method
> called?

The Eiffel GC in the runtime I'm using GC the mark and sweep algorithm.
To the best of my knowlege it goes somthing like this:
Start with set of all objects + the root object.
Recursivly follow references from the root object marking each object reached.
Destroy all objects that are not marked.
So event if you have some big structure with cycles where everything is
referenced, if it is not reachable from the root it gets killed.
There is no way to know if an object is "in use", if it isn't it gets collected
somtime later, in any case, if you have a reference to an object in order to
ask it if it is in use the it is because yuo have a reference to it.

> The best way seems to be to just have an Eiffel object with no
> explicit refcounts on a GtkObject, and then when the 'destroy' signal on the
> GtkObject fires, you mark your Eiffel object as being no longer in use. You
> also have a way to turn a GtkObject into an Eiffel object
> (gtk_object_[gs]et_data() :).

Storing a reference to an Eiffel object in GTk object data is no problem
although it is a bit tricky because Eiffel objects are moved around by the
GC quite often.
The things is, I want to be able to remove an eiffel object from it's parent,
and have the GTK object live on until it gets reparented. I want to hold a
refernece on the GTK obj for this reason. (So I dont have to catch every reparenting
operation with the right ref wrappers.)

> Since the GtkObject has the final word on whether the "object" lives or
> dies, and is in fact the "real" object, you shouldn't need to necessarily
> have an Eiffel object around even when the GtkObject is still alive. The
> Eiffel object is only used by Eiffel stuff, not by gtk+, so you should
> ignore any gtk+ refcounts when determining whether the Eiffel object lives
> or dies.

I would love to have super thin stateless wrappers and just make a new one
for every C pointer I come accross and destroy them when I'm done, letting
the GTK object be the real object but wearing a new shell every time it
pops into eiffel land. The problem is I can't because if I see a pointer
to a GtkHBox I have no idea if I should create an EIFFEL_H_BOX or a
EIFFEL_COMPLICATED_TOOLBAR_THING that happens to look like a GtkHBox
from the outside. Perhaps there is some way that I can store the type
in the object data, Eiffel is staticaly types so I can't exactly do
this but I might be able to store a pointer to a factory or somthing
like that.

> Another data point - What the ObjC bindings do is keep the ObjC Object alive
> until the 'destroy' signal is received on the gtk+ object. If the ObjC
> object is freed explicitly, the signal handler is removed and then the
> GtkObject is destroyed. No reference counts either way are involved.

The features i am tyring to achive are:
Coupling:
	Eiffel object never exists without GTK object.
	GTK object may exist without eiffel object if
	I find a good way to make a new Eiffel object
	from the GTK object.

Garbage:
	Unreachable (from eiffel) eiffel objects
	connected to unreachabe (from eiffel through
	some GTK refrence path) GTK objects.

Not garbage:
	Unreachable (from eiffel) eiffel objects
	connected to reachable (from eiffel through
	some GTK refrence path) GTK objects.

	GTK objects connected to reachable (from eiffel)
	eiffel objects.

> 
> Besides, the gtk signal system needs to acquire & release refcounts on
> objects, which would cause a nice amount of infinite recursion if your
> suggestion were to be implemented.
> -- Elliot

I will investigate the "Make new eiffel objects from GTK ones just in time"
angle further.
Would somthing like the weakref system get around the loopieness problem?
It seems to be just a linked list of function/data pairs. It seems to me
that this would work, just call the list in _ref and _unref, obviously
you can shoot yourself in the foot quite easily if you change a reference
in the callback, this could be just bad luck or I could keep a little
context stack to detect cycles and raise an exception.

Perhaps a good idea will arrive avter I've slept some.

Sam