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
