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



Hi Draghi,

On Tue, 2002-01-08 at 09:37, Draghi Puterity wrote:
> 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.

	Sounds much nicer.

> 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.

	The AT-SPI callbacks come in from the glib mainloop, there's no real
reason why you can't use glib to do the polling for you, and have a
single mainloop, and a single thread - poll on the braille reader, and
get the callbacks all with minimal complexity and no locking :-)

> > 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.

	Oh - well; the API user shouldn't have to worry - the cspi/libspi APIs
should be fully re-enterant - if they are not that's a bug [ I'm working
on making them so right now ].

	So - don't worry :-)

		Michael.


-- 
 mmeeks gnu org  <><, Pseudo Engineer, itinerant idiot




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