I am no expert in this area but I will attempt expand a bit on Mr Davis' answer. If I were you I would start looking at http://library.gnome.org/devel/glib/stable/glib-The-Main-Event-Loop.html. Also download the sources and dig though glib/gmain.c.
The short answer is that the main loop does not use threads at all. At least not that I could detect by looking through the glib sources. I am not clear on how GDK integrates with the main loop. I guess it is possible that it uses separate threads but I would be surprised if that were the case.
The core of the (GLIB) main loop is the poll() function (or something that looks like it). See the man paged for more on poll(). In glib/gmain.c there are two custom implementations of poll(). Both are called g_poll(). If the OS you are on does not provide a system implementation of poll() then one of the other two are used. If you are on a WIN32 platform the first one is used, otherwise the second one is used. The second simply simulates what poll() does using select(). The WIN32 one is rather complicated and tries to process the content of the Window message pump as well as waiting for "EVENTS" using WaitForMultipleObjects(). On unix systems the core of the main loop relies on the fact that file descriptors could represent more than just regular disk files. Unfortunately Windows does not work that way.
A cursory glance at the gdk code makes me think it relies on the glib main loop for input processing. If you look at gdk/x11/gdkevents-x11.c the _gdk_events_init() function seems to get a file descriptor that is assigns to a GdkDisplaySource (derived from GSource?) which is attached to the default main loop using g_source_attach(). So it seems that at least on X11 no additional threads are needed to get input events. I noticed that there are also gdk/win32, gdk/quartz, gdk/linux-fb and gdk/direct-fb directories. Who knows if any of them rely on threads to capture user input. I would be surprised if that were the case for win32 and quartz since the underlying OS likely takes care of that for us.
Hope that helps. Again, I am no expert. If I misspoke I am sure someone will correct me. :)
Peter Long
----- Original Message ----
The short answer is that the main loop does not use threads at all. At least not that I could detect by looking through the glib sources. I am not clear on how GDK integrates with the main loop. I guess it is possible that it uses separate threads but I would be surprised if that were the case.
The core of the (GLIB) main loop is the poll() function (or something that looks like it). See the man paged for more on poll(). In glib/gmain.c there are two custom implementations of poll(). Both are called g_poll(). If the OS you are on does not provide a system implementation of poll() then one of the other two are used. If you are on a WIN32 platform the first one is used, otherwise the second one is used. The second simply simulates what poll() does using select(). The WIN32 one is rather complicated and tries to process the content of the Window message pump as well as waiting for "EVENTS" using WaitForMultipleObjects(). On unix systems the core of the main loop relies on the fact that file descriptors could represent more than just regular disk files. Unfortunately Windows does not work that way.
A cursory glance at the gdk code makes me think it relies on the glib main loop for input processing. If you look at gdk/x11/gdkevents-x11.c the _gdk_events_init() function seems to get a file descriptor that is assigns to a GdkDisplaySource (derived from GSource?) which is attached to the default main loop using g_source_attach(). So it seems that at least on X11 no additional threads are needed to get input events. I noticed that there are also gdk/win32, gdk/quartz, gdk/linux-fb and gdk/direct-fb directories. Who knows if any of them rely on threads to capture user input. I would be surprised if that were the case for win32 and quartz since the underlying OS likely takes care of that for us.
Hope that helps. Again, I am no expert. If I misspoke I am sure someone will correct me. :)
Peter Long
----- Original Message ----
From: 刘志波 <boerliu@xxxxxxxxx>
To: paul@xxxxxxxxxxxxxxxxxxxxx
Cc: gtk-list@xxxxxxxxx
Sent: Friday, December 7, 2007 1:27:10 PM
Subject: Re: Is GTK+-(GDK) implemented by Multi-thread method?
Thanks a lot!
To: paul@xxxxxxxxxxxxxxxxxxxxx
Cc: gtk-list@xxxxxxxxx
Sent: Friday, December 7, 2007 1:27:10 PM
Subject: Re: Is GTK+-(GDK) implemented by Multi-thread method?
Thanks a lot!
2007/12/8, Paul Davis <paul@xxxxxxxxxxxxxxxxxxxxx>:
On Sat, 2007-12-08 at 02:09 +0800, 刘志波 wrote:
> Hi forks,
> I want to know whether the GTK+- Library is implemented by
> Multi-thread method for itself. You know, it has been driven by event
> mechanism. How does GTK's main loop catch user events like key events,
> mouse motion,etc when other flows alway hold the CPU resource? I know,
> maybe the GTK lib can use the signal to receive all of the hardware
> events. I just want to know the GTK wheter uses the Multi-thread
> mechanism to program itself!
no.
_______________________________________________ gtk-list mailing list gtk-list@xxxxxxxxx http://mail.gnome.org/mailman/listinfo/gtk-list
