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

[Michael Meeks <michael ximian com>]

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 ?

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

	I don't quite know what SetTimer does - but see glib/glib/gmain.c -
they seem to use SetTimer in their 'poll' emulation for Unix - so, if
you want to just idle waiting for an event or timeout - then yes, we
provide cross platform hooks to do that nicely.

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

	The callbacks always come in the same thread - assuming you have only
one thread in the mainloop - otherwise it's unpredictable. Having a
single thread running the mainloop is the reccommended mode of
operation.

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

	HTH,

		Michael.

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