GNOME.org
 

Re: GTK and threaded applications

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

Michael L Torrie wrote:


On Wed, 2006-02-01 at 10:44 +0100, kornelix wrote:
Thanks for your generous help. I will try Michael's suggestion and see how it works.
I would like to implement all GTK calls in the main program as Tristan suggested, but this seems to be very complex (must implement asynch. queues of data going back and forth between threads and main(), where screen updates and user inputs take place.
Question: it seems to me that GTK puts the burden of locking (and the responsibility to understand GTK internals) in the wrong place: the user of GTK. Would it not be better if GTK took care of its own locking and blocking in those places where it is necessary? Is this in the roadmap for GTK, or should it be? 

I believe if such locking were made automatic in the GTK  libraries
themselves, we'd be open to possible deadlock situations.  Better to
leave the locking in control of the programmer who can then resolve any
deadlocks in his code.
I have written multi-threaded applications in Win32, and I never worried about locks and thread blocking (except for my own application's business). 

It has been nearly 8 years since I did any Win32 GUI programming, but at
the time I recall that because the Win32 GUI calls had to be
synchronized too, I ended up have a thread just for the gui and had a
message queue that I used to send it messages to change things in the
GUI.  So unless you were using a toolkit that hid the synchronization
details from you (not MFC!) then perhaps you were lucky you didn't have
any problems.


I have not looked at KDE. Any better?


Qt is now supposed to be thread-safe as of somewhere in version 2 (we're
now up to 3.3 and 4.1).  I don't know how they implement the
synchronization stuff.

Michael




thanks again,
Mike



_______________________________________________
gtk-app-devel-list mailing list
gtk-app-devel-list gnome org
http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]