gtk/main_loop.cc and threads

[GoogleCodeExporter]

Looking at google-gadgets/ggadget/gtk/main_loop.cc there is code to
create and use a "wake up pipe" to wake up the main loop thread when a
source is added to the main loop.

This cannot possibly be right. There are only two situations:

 - g_thread_init() has been called. In this case GLib will internally
   wake up the main loop thread (using its own wake up pipe) whenever 
   necessary.

 - g_thread_init() has not been called. In this case you *must not*
   use the main loop from a thread different from the thread where
   the main loop is running. Accesses to the main loop will not
   be protected by a mutex and a crash will eventually occur.

Original issue reported on code.google.com by owtay...@gmail.com on 12 Jun 2008 at 1:23

[GoogleCodeExporter]

Thanks for your report. So do you mean that g_thread_init() must be called 
explicitly?

Original comment by james...@gmail.com on 12 Jun 2008 at 1:27

[GoogleCodeExporter]

If the code in question is called from multiple threads, then yes, someone
has to explicitly call g_thread_init(). 

You could simply expect that host applications do it (that is, add it at
the top of hosts/gtk/main.cc), but since threads are created and used 
internally - 
for example, from the curl code - it's probably better to do it inside the
google gadgets library. So, maybe add to the MainLoop::Impl constructor:

   if (!g_thread_supported())
      g_thread_init(NULL);

Note also that without calling g_thread_init() GStaticMutex is a no-op.

Original comment by owtay...@gmail.com on 12 Jun 2008 at 2:14

[GoogleCodeExporter]

Thanks for your suggestion. We'll fix it asap.

Original comment by james...@gmail.com on 13 Jun 2008 at 4:35

[GoogleCodeExporter]

Original comment by james...@gmail.com on 13 Jun 2008 at 6:02

• Changed state: Accepted

[GoogleCodeExporter]

Should be fixed in 0.9.3. Please reopen if not.

Original comment by james...@gmail.com on 13 Jun 2008 at 2:16

• Changed state: Fixed