Re: [g-a-devel]Re: at-spi callbacks
- From: David Bolter <david bolter utoronto ca>
- To: Bill Haneman <bill haneman sun com>
- Cc: gnome-accessibility-devel gnome org
- Subject: Re: [g-a-devel]Re: at-spi callbacks
- Date: Fri, 03 May 2002 11:05:55 -0400
Thanks very much Bill:
Bill Haneman wrote:
On Thu, 2002-05-02 at 18:57, David Bolter wrote:
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.
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.
Okay, that and the fact that ORBit2 is not multithreaded helps my
understanding a great deal.
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.
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 ;-)
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.
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
] [Thread Prev