Re: [g-a-devel]Re: at-spi callbacks

[David Bolter <david bolter utoronto ca>]

Thanks very much Bill:

Bill Haneman wrote:

> On Thu, 2002-05-02 at 18:57, David Bolter wrote:
>
> > Hi Bill,
> >
> > I was wondering if you could give me some insight with respect to the 
> > at-spi.  When I register a callback with the at-spi ("focus:" for 
> > example), I have noticed that it is possible for the listener to be 
> > called before a former call has finished.  This has led me to suspect 
> > that a thread is created for each call.  However using a mutex hangs the 
> > gok during these ocurrences.  I admit I am rather green with 
> > multithreading on unix/linux, and so am perhaps not making much sense.
>
> Hi David:
>
> The problem is not really one of threading (in this situation) but one
> of re-entrancy.  This is inherent to CORBA, since any synchronous CORBA
> call can block, but in some cases a callback on the "other side" of the
> exchange can reenter (e.g. "call back").
>
>
> > What is the suggested way to avoid callback collisions?  Should the gok 
> > be made thread safe?  Can you advise?
>
> Thread safety won't help since this doesn't prevent reentrancy.  Event
> listeners of at-spi are called from the registry.  Since the listeners
> are in effect CORBA servants, they mustn't block while a client-side
> CORBA call is being processed, otherwise you'd have deadlock... 
Indeed, I saw deadlock (though rarely) when I tried a mutex.

> example: gok calls at-spi using a synchronous call (i.e. a call that is
> not a CORBA oneway).  This must block, but if the CORBA call results in
> event generation which must be delivered to a listener, the gok's
> listener servant must be active even while the client-side call is
> blocked.  In this situation, indeed, the GOK listener code will be
> called while the GOK client-side call is blocking on the CORBA I/O.
Okay, that and the fact that ORBit2 is not multithreaded helps my 
understanding a great deal.

> So perhaps this will help you figure out what to do; the basic answer is
> that listener code should be re-entrant.  That doesn't mean that all of
> GOK must be re-entrant, only that operations that are carried out in
> listeners should not collide with code that may be waiting on a
> client-side call.  This has implications for things like adding/removing
> items from linked lists, etc.  Fortunately you don't have to worry about
> thread-safety issues like memory access race conditions and atomicity,
> just re-entrancy - because ORBit2 is not, at the moment, multi-threaded.
As you have probably gathered from my earlier message, dealing with 
reentrant calls from a non multi-threaded environment is quite 
mysterious to me.  The gok was seg faulting during reentrancy, which I 
thought was having to do with memory race conditions.  I suppose hunting 
down exactly why will be a learning experience ;-)

Here is an overview of what is happening when things go wrong:

the gok gets a focus event
the gok interrogates the at-spi
during interrogation the gok gets another focus event
soon after that the gok seg faults (or, if using blocking we hang).

Any further thoughts welcome.

The gok focus callback currently in cvs, is checking a flag and quickly 
returning if it is a reentrant call.

(Is there a plan to make ORBit2 multi-threaded?)

cheers,

~~David

> HTH,
>
> -Bill
>
>
> > I did find a related thread on the dev list (from January I think) but 
> > it was not clear to me how things got resolved.
> >
> > thanks,
> >
> > ~~David
>
>
> _______________________________________________
> Gnome-accessibility-devel mailing list
> Gnome-accessibility-devel gnome org
> http://mail.gnome.org/mailman/listinfo/gnome-accessibility-devel