Re: [gtk-list] Threading and glib main

[Owen Taylor <otaylor redhat com>]

Kai Wetzel <k.wetzel@welfen-netz.com> writes:

> Hi,
> 
> I was thinking of using a seperate mainloop for another thread
> when I realized (read in the reference manual) that the glib
> main loop is global.  I'd mainly like to watch for input on
> some fds in a thread which is not the one where the GUI stuff is
> beeing handled, with as little effort as possible.
> 
> I had the following alternative ideas:
> 
> - handling read-ready on the X fd is done in another thread, not
>   the thread calling select.  So all Gtk works would just
>   be done there on default, including calls to XSync.  Is there a
>   way to do this with a (few) call(s) ?

There is no way you are going to get GTK+ working without
having the X filedesciptor handled by g_main_*. And, as you
say, only one mainloop can exist. I may try to fix this for
GLib 1.4, so you can have completely independent mainloops
running in different threads.
 
> - use one seperate thread for running the select loop (custom,
>   not glib) for the other fds.  While a little more work than
>   the other idea, could Gtk+ live with this and would I just need
>   to call g_main_wakeup or set an idle handler to "notify" the
>   main thread carrying select ?

You can do whatever you want with select() in a different thread,
as long as the sets of file descriptors that the main loop is
handling and the sets of file descriptors that you are handling
are distinct.

g_main_wakeup() is not an exported function, but an idle handler
will work if you have something that must be done in the main
thread. Of course, there is no reason you can't make GTK+/GDK
calls directly in the thread that select()'s, as long as you
surround them with gdk_threads_enter()/gdk_threads_leave().

Regards,
                                        Owen