Re: [g-a-devel]HEADS-UP: at-spi event refcount change

[David Bolter <david bolter utoronto ca>]

Bill Haneman wrote:

> On Tue, 2002-07-16 at 22:18, David Bolter wrote:
>
> > Just a quick (and late) note, that I really appreciated this heads up 
> > and would very much like as much detail as possible as work progresses.
>
> Hi David, 
>
> Sure, glad this was useful.  The work in question was done pretty much
> the same day that the email was written.
>
> I am a little puzzled by what you mean by "would like as much detail as
> possible" since I don't believe anything in gok can be / has been
> impacted by this change.
Fair enough.  

I am not sure if I am clear on the ref issue.  Please consider: when I 
am storing accessibles, for example, when we get a focus event, we walk 
up the tree and store a pointer to the root accessible (application), 
and then when we get another focus event, we walk up to the root, and 
check it against our stored pointer.  So if we are using the cspi 
bindings, we should add a ref presumably using Accessible_ref?  When we 
are no longer concerned with an accessible do we unref?  and if so, when 
does it become invalid?  Presumably when the ref count is zero, but I 
have seen discussions that have led me to believe this is not the case?

So I guess I can't help but be curious how things are done, even though 
it shouldn't affect the gok, it is reassuring to know what is going on 
underneath.  But I could always look at the code ;-)

Also, I was pleased to see that the events are synchronous and ordered, 
and I do believe that is relevant to the gok.  We have had problems with 
collisions in the past.

cheers,

~~David

> -Bill
>
> > cheers!
> >
> > David
> > GOK project
> >
> > Bill Haneman wrote:
> >
> > > Hi:
> > >
> > > In dealing with a number of bugs filed against AT-SPI and also
> > > ORBit2/linc, the decision has been made to make at-spi's event listener
> > > "notifyEvent" call drop the "oneway" directive.
> > >
> > > This is because the use of oneways is inherently problematic when large
> > > numbers of calls are being made by an ORB client, and in servicing those
> > > calls, synchronous callbacks from the server result.  The problem
> > > appears to be quite intractable from an ORB/CORBA point of view, without
> > > introducing new, nonstandard API in the ORB itself.  Some client-side
> > > workarounds suggest themselves, for instance relying on a async
> > > 'handshake' periodically from client to server, to ensure that the
> > > server-side ORB is not being overloaded.  However the additional problem
> > > of ORB event reordering in oneway calls would remain, and even those
> > > solutions would require POA policy changes from the ORB and could not be
> > > guaranteed to work across various ORBs.  
> > >
> > > The change has the following effects:
> > >
> > > (1) application latency can be increased since the atk-bridge's event
> > > calls are now synchronous.  This will eventually be remedied by the use
> > > of an event queue in the atk-bridge itself.
> > >
> > > (2) event reordering no longer occurs as a result of ORB reentrancy in
> > > servicing notifyEvent calls; this is a win since numerous bugs have been
> > > filed against the event reordering.
> > >
> > > (3) since event notification is synchronous, we no longer have to rely
> > > on the remote server to unref() the event source once the notifyEvent
> > > call has been serviced; this reduces the number of synchronous calls
> > > required greatly, and has allowed the elimination of many ref()/unref()
> > > pairs.
> > >
> > > It does, however, mean that listeners are no longer expected to unref()
> > > the sources of the events they receive.  For AT clients using the CSPI
> > > bindings there is no apparent effect since the unref() was handled
> > > previously by the CSPI bindings, but any AT clients which used the CORBA
> > > bindings directly should remove the unref() call at the end of their
> > > notifyEvent server-side implementation.  The only affect on users of the
> > > CSPI bindings is this: if CSPI clients wish to use direct pointer
> > > comparison to test the identity of two Accessible object instances, they
> > > must ensure than an explicit reference to both objects is held by the AT
> > > client, e.g. the AT client must have called "ref()" on the accessibles
> > > before comparing them.  Alternatively, a client can call
> > > cspi_object_equals () rather than using the pointer comparison 
> > > ("a == b").
> > >
> > > The only clients known to be affected at this time are the java
> > > accessibility bridge sample clients, but I felt it was important to
> > > inform the whole GNOME Accessibility development community of this
> > > change in policy.  As I said, no impact on existing AT vendor code is
> > > anticipated as a result of this change.
> > >
> > > The changes discussed here are in CVS HEAD, at-spi version 1.1.0, and
> > > will be bundled with GNOME 2.0.1 and later.  GNOME 2.0.0 will ship with
> > > the previous implementation, and be based on at-spi-1.0.X.
> > >
> > > thanks and best regards,
> > >
> > > Bill
> > >
> > > _______________________________________________
> > > Gnome-accessibility-devel mailing list
> > > Gnome-accessibility-devel gnome org
> > > http://mail.gnome.org/mailman/listinfo/gnome-accessibility-devel