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

[Bill Haneman <bill haneman sun com>]

Draghi Puterity wrote:
...
> 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'm not familiar with this Windows API, but glib provides some API which
is useful for implementing timers and timer-based event callbacks; see
the documentation in
glib/docs/reference/glib/html/glib-the-main-event-loop.html and
glib/docs/reference/glib/html/glib-timers.html (in a built copy of glib
from Gnome CVS, or check the developer.gnome.org/docs/API online docs). 
If you use the glib main loop (used by GTK+) then the g_timeout_add ()
functions are probably the most useful, otherwise you can use the
g_timer () API.

> 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 cspi listener callbacks API specify that the callbacks are
in-process, and they are always called from the same thread at the
moment.  

For various reasons the cspi event loop now always uses the glib main
loop (there was no advantage in using the CORBA event loop instead,
Michael convinced me), so this behaviour should be the same whether or
not you are a GTK+ app.

Best regards,

Bill

> 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