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

[Marc Mulcahy <marc mulcahy sun com>]

Hi All:

Presumably if you use a queue for events, you'd use something like a glist 
or a gslist, in which case you could still have re-entrancy hazzards when 
you remove stuff from the queue.  Not a problem, just something to watc our 
and plan for...

Marc

At 05:31 PM 5/3/2002 +0200, 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
>
> ----- 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