Object referencing in ATK

["Padraig O'Briain" <Padraig Obriain Sun COM>]

This is my current thoughts on this subject. I would apprciate any feedback you 
can offer.

I am trying to understand the life cycle of an AtkObject and ensure that
it is destroyed when its corresponding GtkWidget is destroyed and that
code which uses the ATK interfaces can safely refer to an AtkObject
even if its underlying GTK widget has been destroyed.

When an ATK object is created for a widget and returned by a call to 
gtk_widget_get_accessible() the ATK object has a reference count of 1.

When a widget is destroyed the ATK object is unreferenced in 
gtk_widget_finalize() and will be destroyed is noboby else has a reference
to it.

This leaves the following problem:

If code, which used the ATK interface to obtain a pointer to an ATK object, 
subsequently passes this ATK object as an argument there is no guarantee 
that the GTK widget has not been destroyed in the intervening period.

I an assuming that code which returns an ATK object pointer will be executed 
in a GTK signal handler and therefore we are guaranteed that the GTK widget 
underlying the ATK object will continue to exist for the duration of the 
signal handler.

If someone thinks that this is not a safe assumption, I would appreciate
hearing from them.

If it is desired to make calls which refer to the ATK object subsequently 
it will be necessary to call g_object_ref() on the ATK object to ensure that
it is not finalized and call g_object_unref() when the ATK object is no 
longer required.

In this scenario, which is similar to adding a reference to an ATK object
which is part of an AtkRelation, we could have a situation where the
ATK object exists but the GTK widget has been destroyed or finalized.

It seems that we need some way of indicating that the ATK object is unsafe.
Looking at GTK it seems that this is done by setting the flags field of
GtkObject to GTK_DESTROYED. 

When a GTK widget is destroyed I think that we need to indicate that the 
current ATK object is destroyed. We also need to ensure that the
widget field of GtkAccessible is set to NULL when the widget is destroyed
to prevent inappropriate access.

When an accessible object is created by a widget in the GAEL library I 
propose to connect to the destroy signal of the widget and set the
widget field of GtkAccessible to NULL in that signal handler.
If the code in the GAEL library which refers to widget field of GtkAccessible
checks that it is non-NULL before calling it then we will not refer to
a destroyed object.

The other question is whether we need to provide a mechanism for a user of
the ATK interface to determine whether an ATK object refers to a destroyed
object.

If we do I propose to add a state ATK_STATE_DESTROYED to AtkState.





> Subject: Re: ATK tarball and GTK+ diff tarball
> To: otaylor redhat com, Padraig Obriain Sun COM
> Cc: timj gtk org, hp redhat com, gnome-accessibility-list gnome org
> MIME-Version: 1.0
> Content-MD5: 51/9QzJXLA1qTtKY1ccH7w==
> 
> >Owen,
> >
> >>  
> >>  * Memory management for AtkRelation/AtkRelationSet obviously
> >>    needs some thinking through. Does AtkRelation hold strong
> >>    references on the target? 
> >> 
> >>    AtkRelation/AtkRelationSet either need to be value objects
> >>    that can be copied, or they need to be GObjects, These
> >>    are basically the only memory management models that work
> >>    for language bindings.
> >> 
> >
> >By strong references, do you mean that g_object_ref() has been called on the 
> >AtkObjects in the target? If so, the answer is no.
> 
> FYI, we are re-thinking this, probably we will ref the AtkObjects that are in 
> a RelationSet.  This will likely be a part of the overall overhaul (pardon the 
> phrase) of AtkRelationSet that Padraig is doing at the moment.
> 
> -Bill
> 
> ------
> Bill Haneman x19279
> Gnome Accessibility / Batik SVG Toolkit
> Sun Microsystems Ireland 
>