Re: [g-a-devel]Re: Gail Range strangeness ...
- From: "Draghi Puterity" <mp baum de>
- To: "Michael Meeks" <michael ximian com>
- Cc: "accessibility mailing list" <gnome-accessibility-devel gnome org>
- Subject: Re: [g-a-devel]Re: Gail Range strangeness ...
- Date: Tue, 8 Jan 2002 10:37:42 +0100
> 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
> > to avoid processing information on different threads. So we will
> > 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
> > SR to call you from a single thread, which is our main loop thread. Can
> > foresee any problem if we call you outside any of your callback
> 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.
] [Thread Prev