Re: thread support in Windows: problem

["fkater googlemail com" <fkater googlemail com>]

On 11:37 Thu 24 Jan     , Tor Lillqvist wrote:
> > I am trying to run a simple(st) thread example in GTK with a
> > windows-MinGW-Msys development environment
>
> Don't bother. You should not call GTK+ functions from multiple threads
> on Windows. It won't work. There are deep technical reasons for this,
> fixing it is in no way trivial. This has been mentioned several times
> over the years on this mailing list.

I've tried to make gtk work with threads on win32 and linux for a long 
time now and I am finally proud to say, it is possible -- but, as Tor 
said, not trivial.

Just some notes on how to make the first steps towards that:

Write wrapper functions for any gtk operation you'd like to execute from
threads in a way that the thread calls a glib's idle function which does
the real gtk work. Additionally (!) you need to lock gtk/gdk access by 
the gds_threads_enter/leave functions -- since idle functions are not
auto-locked by gtk (like signals are).

When you get deeper into this topic you'll probably stuble accross the
problem that idle functions are kind of a one way: you can launch an
idle function e.g. to rename a label but what if you want to read out
the current value of an entry widget? You want the result right when you
ask, however the idle function comes back at some later point of time.
The solution I took was not to wait for that idle function but create
wrappers for the gtk widgets which keep the data and can be queried
without asking gtk; this of course needs you to update the data whenever
the user changes the real gtk widget.

Good luck, it IS possible.

Felix