Re: Object referencing in ATK

[Peter Korn <peter korn sun com>]

Hi Padraig,

> 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.
> 
> ...
> 
> 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.

I don't think this is safe.  With the latency involved in the multiple layers
between GTK+ and the AT SPI to the AT itself, I don't think we can insist that
this be a synchronous operation.  So the signal would fire, the event would be
queued, the signal handler would return, and then sometime later the AT would ge
the signal and start making queries on the AtkObject source of the signal.  By
that time the GtkWidget could have been disposed.

> 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.

This problem isn't without precedent.  We already anticipate situations in which
AtkObjects are not attached to a GtkWidget - flyweights.  In those cases we had
talked about a TRANSIENT state to indicate this.  An accessible state change
might be a good way to indicate to an AT that the AtkObject is no longer
attached to a GtkWidget.

And just because the AtkObject isn't attached to a GtkWidget, the AT may still
want to keep the object around, to make queries about it (about it's last known
state, prior to being disassociated).

Finally, don't we have a notion of child destroyed events?  Should not the
AtkObject referencing the GtkWidget's parent get a child destroyed event (sorry,
signal)?

> 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.

I wonder if it wouldn't make more sense to change the meaning (and name) of the
TRANSIENT state to something like ATK_STATE_DISASSIOCIATED - to cover the more
general case that this AtkObject is not associated with an underlying Widget
(Gtk or otherwise).


Peter Korn
Sun Accessibility team

> > 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
> >
> 
> _______________________________________________
> gnome-accessibility-list mailing list
> gnome-accessibility-list gnome org
> http://mail.gnome.org/mailman/listinfo/gnome-accessibility-list