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

["Draghi Puterity" <mp baum de>]

Hi David, hi Bill,

why don't you use a queue for the SPI events? After you are done with
processing one event, just get the next one from the queue, process it and
repeat this steps until the queue is empty. Do you see any drawbacks with
this approach?

Draghi

----- Original Message -----
From: "David Bolter" <david bolter utoronto ca>
To: "Bill Haneman" <bill haneman sun com>
Cc: <gnome-accessibility-devel gnome org>
Sent: Friday, May 03, 2002 5:05 PM
Subject: 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?)
>
> 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
> >
>
>
>
> _______________________________________________
> Gnome-accessibility-devel mailing list
> Gnome-accessibility-devel gnome org
> http://mail.gnome.org/mailman/listinfo/gnome-accessibility-devel