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



Hi Michael,


> Hi Draghi,
>
> On Mon, 2002-01-07 at 15:51, Draghi Puterity wrote:
> > 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.
>
> Sounds reasonable - I wish we could help you with the ORB here; why do
> you need a separate thread to handle the braille reader ? is the process
> not even driven in some way ? is there not a device you can poll on in a
> glib mainloop and do non-blocking IO on ?

The SR right now is for the moment a console app, so it doesn't have a glib
mainloop. We don't need a separate thread for the Braille reader, it is so
now because we have implemented the input polling for Braille with sigaction
(SIGALRM, ...) and  setitimer(...). I didn't liked that from the begenning
since the timer seems to be unique for the proces but it worked for the
moment.We could change that and pool from the mainloop with nonblocking IO,
thus having the input on the polling thread.  This will change the nature of
the Braille component from push to poll. However we will need to cope with
more threads also because of AT-SPI callbacks and so on, so we need to do
some queueing anyway.

.................

> > 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)?
>
> It's important that the code re-enters elegantly even in the same
> thread - since we were getting some list management corruption
> otherwise; that is now fixed.

Could you give me some examples of what *** not *** to do.

Best regards,

Draghi





[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]