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

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?)





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.



Gnome-accessibility-devel mailing list
Gnome-accessibility-devel gnome org

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]