Re: GTK and threaded applications

[Michael L Torrie <torriem chem byu edu>]

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