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

[David Bolter <david bolter utoronto ca>]

Draghi Puterity wrote:

> 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, I haven't got deep enough into the specific cause of the problem 
to be able to say that a queue would work for us (I'm actually tasked 
with something else at the moment).  I have tried a linked list queue 
which I polled but it didn't work for me.  Maybe if I used an array it 
would be better.  I have looked at the gnopernicous code and it seems 
reasonable.  Have you noticed any problems?  Have you tried stress 
testing it?

humbly,

~~David

> 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
>
> _______________________________________________
> Gnome-accessibility-devel mailing list
> Gnome-accessibility-devel gnome org
> http://mail.gnome.org/mailman/listinfo/gnome-accessibility-devel