Re: GTK and threaded applications

[kornelix <kornelix yahoo de>]

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 have written multi-threaded applications in Win32, and I never worried 
about locks and thread blocking (except for my own application's business).

I have not looked at KDE. Any better?

thanks again,
Mike

> Just put the gdk_* threads and flush calls around the actual GTK calls.
> that way only gui updates themselves are put in mutexes (locked).  The
> way you are currently doing it, your actual business logic ends up in
> the mutex, and so if it is lengthy, it will block all the other threads.
>
> Michael
>
>  

> IMO,
>      overall you'll have a cleaner program design if you put
> all your GUI interaction in the main thread.
>
> Now if I'm reading you right; what your experiencing is normal,
> calling gdk_threads_enter/leave is locking a global mutex for
> GTK/GDK interaction.
>
> The rule is, you cant have two threads access the GTK+ api
> at once, so:
>      o You can have a multithreaded application using GTK+
>      o You can even go to the extreme of calling GTK+ functions
>        from seperate threads, but you must take care to lock
>        GTK+ down with gdk_threads_enter/leave()
>      o You *cant* call GTK+ functions from more than one thread
>        and expect GTK+ to execute simultainiously.
>
> Cheers,
>                          -Tristan