Re: GTK and threaded applications

[Daniel Atallah <daniel atallah gmail com>]

On 2/3/06, kornelix <kornelix yahoo de> wrote:
>   I last reported that GTK was making my multi-threaded application run
> as multiple single threads, one after the other. It was suggested to
> lock only the GTK calls instead of the whole thread. I tried this.
>
> I wrapped the individual GTK calls as follows:
>    gdk_threads_enter();
>        do GTK calls to update the GUI or get user input
>    gdk_flush();
>    gdk_threads_leave();
>
> I managed to lock up my system so badly that I had to power off and
> reboot. I think the core problem is that some of my functions can be
> called from within main() dialogs and also from within thread dialogs.
> Hence calling "gtk_threads_enter()" was likely invalid when being called
> from a dialog that was initiated from a menu created in main().
> Correct?  Then I need to write different versions of my functions, with
> and without "gtk_threads_enter()" etc., and make sure the right version
> is being called. Correct? Or perhaps keep track of whether I am in
> main() or a thread, and conditionally execute the above function calls
> (there must be a library function that can tell me if I am in a thread
> or not).
>
> If I have understood the implications correctly, then writing
> multi-threaded applications with GTK may be possible, but I am almost
> ready to give it up because of the complexity and limitations. I will
> check how hard it will be to convert my application to QT or X11 Motif.
>
> FYI, here is something I pulled from the Microsoft web site on Win32
> programming with threads.
>
> << begin Microsoft
>
> MSDN Library
> <http://msdn2.microsoft.com/en-us/library/ms123401%28en-us,MSDN.10%29.aspx> > Development
> Tools and Languages
> <http://msdn2.microsoft.com/en-us/library/ms310242%28en-us,MSDN.10%29.aspx> > Visual
> Studio
> <http://msdn2.microsoft.com/en-us/library/ms269115%28en-us,VS.80%29.aspx> > Visual
> C++
> <http://msdn2.microsoft.com/en-us/library/60k1461a%28en-us,VS.80%29.aspx> > Programming
> Guide
> <http://msdn2.microsoft.com/en-us/library/ms173251%28en-us,VS.80%29.aspx> > General
> Concepts
> <http://msdn2.microsoft.com/en-us/library/9ec4c5e4%28en-us,VS.80%29.aspx> > Multithreading
> <http://msdn2.microsoft.com/en-us/library/172d2hhw%28en-us,VS.80%29.aspx> > Multithreading
> with C and Win32
> Visual C++
> Multithreading with C and Win32
>
> Microsoft Visual C++ provides support for creating multithread
> applications with 32-bit versions of Microsoft Windows: Windows XP,
> Windows 2000, Windows NT, Windows Me, and Windows 98. You should
> consider using more than one thread if your application needs to manage
> multiple activities, such as simultaneous keyboard and mouse input. One
> thread can process keyboard input while a second thread filters mouse
> activities. A third thread can update the display screen based on data
> from the mouse and keyboard threads. At the same time, other threads can
> access disk files or get data from a communications port.
>
> With Visual C++, there are two ways to program with multiple threads:
> use the Microsoft Foundation Class (MFC) library or the C run-time
> library and the Win32 API. For information about creating multithread
> applications with MFC, see Multithreading with C++ and MFC
> <http://msdn2.microsoft.com/en-us/library/975t8ks0.aspx> after reading
> the following topics about multithreading in C.
>
>  >> end Microsoft
>
> This was my experience writing a multi-threaded application for Win32. I
> did not have to single-thread the Win32 calls themselves, I only had to
> worry about the obvious things like conflicting access to data or two
> threads writing to the same window at the same time.
>
> GTK gurus, please put this on your roadmap. Threads need to work without
> the user having to manage this with extra complexity and the risk of
> subtle bugs. GTK functions need to assume they are in a threaded
> environment and do their own locking. Making the user worry about this
> is wrong. Since obtaining a lock requires nanoseconds, this should not
> be a performance concern.
>
> regards,
> Mike

It seems to me that you're going about this in the wrong way.

When I read the win32 example of three threads above, that is exactly
what you want to be doing.  You should have your worker threads doing
whatever it is that they need to do - read from the network, process
data, whatever, and when you actually want to update the UI based on
these changes, you need to make sure that you do that in the main
thread.

You can easily get your worker threads to trigger an UI update by
using g_idle_add() to schedule a function to be executed in the main
thread at the next main loop iteration.

-D