Re: [g-a-devel]Re: Gail Range strangeness ...

["Draghi Puterity" <mp baum de>]

Right now the Braille input comes on another thread. A tipical usage
scenario is the following: the user presses some key on the Braille display
sensor strip and the SR gives him more information (i.e. color, font, size),
tipically through speech. Now with the do-it-only-on-demand approach we will
make some AT-SPI calls (through SRO) at that point.

However having more threads in the SR is also iritating for us, and we want
to avoid processing information on different threads. So we will probably
queue all the async input and process everything inside the same thread.
That means for the SR as a console app, that we will need a main loop
waiting for all input (including AT-SPI). If the SR will evolve to a GTK app
we might need to synchnonize with the UI event queue there. BTW what I was
looking for in this context was a GTK equivalent for SetTimer/WM_TIMER in
Windows. Do you know what I'm talking about? Can you tell me something about
it?

How about the AT-SPI callbacks? Are they comming on arbitrary threads or
always on same thread? Is there a difference if we are a console or a GTK
app in this respect?

So, we don't feel a strong need for reentrant AT-SPI now, we will change the
SR to call you from a single thread, which is our main loop thread. Can you
foresee any problem if we call you outside any of your callback thread(s)?

Draghi



----- Original Message -----
From: "Bill Haneman" <bill haneman sun com>
To: "Draghi Puterity" <mp baum de>
Sent: Monday, January 07, 2002 4:07 PM
Subject: Re: [g-a-devel]Re: Gail Range strangeness ...


> Draghi Puterity wrote:
> >
> > >
> > > I'm not convinced that we should put this in cspi since cspi will
never
> > > be called from multiple threads in the same process space, nor will
cspi
> > > data be shared between processes... so I don't see the need.
> > >
> >
> > So, should I understand that we should make AT_SPI calls only from a
single
> > thread in the SR?
>
> Yes, at the moment.
>
> If you feel a strong need to do otherwise, let's talk about it... it's
> possible to make cspi thread-safe but involves some additional work
> which we don't want to do unless it really brings a significant benefit.
>
> -Bill
>
> > Draghi