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

[Bill Haneman <bill haneman sun com>]

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

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.

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.

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
>