re: Multi-threaded GTK+ Win32

["Robin Rowe" <rower MovieEditor com>]

CinePaint is a multi-threaded GTK1 app and is encountering the Win32
deadlock problem Tor describes in the post enclosed below.

Is the situation any better in GTK2 for Windows? Is GTK unsuitable for
multi-threaded Win32 apps?

Thanks,

Robin
-------------------------------------------------------------------
Robin Rowe MovieEditor com   Hollywood, California
www.CinePaint.org   Open source digital motion picture film software

From: Tor Lillqvist <tml iki fi>
To: gtk-devel-list gnome org
Subject: Multi-threaded GTK+
Date: Tue, 6 Nov 2001 13:01:49 +0200 (EET)

It seems that trying to use GTK+ in a multi-threaded application on
Win32 opens up a can of worms, that has until now been largely ignored
(by me, at least). (Bug #60620 is one example. I put in a tentative
hack that seems to fix the immediate problem in the test case attached
to the bug report, but I am sure that in the general case there are
still lots of problems.)

How well is multi-threaded GTK+ supposed to work? Are there real
applications (that might otherwise be useful and portable to Win32)
that do GDK operations on the same windows from different threads?
Would it be a big drawback if, for instance, we would document that in
multi-threaded GTK+ programs expected to run on Win32, all GTK+ calls
should be made in one thread (using gtk_idle_add() or similar if
necessary).

I understand that in X11 the situation is different as the X server
naturally knows nothing about threads in the client, so as long as the
client (GTK+) itself knows what it is doing and uses appropriate
locking, there shouldn't be any problems in operating on the same
windows or other X11 objects from different threads (?).

But Windows knows the thread that created each window, and some
operations on a window from another thread might cause lots of fun
like deadlocks unless the application programmer is very careful with
what the window owning thread might be doing at the time another
thread tries to operate on the window. Do a Google newsgroup search on
"win32 thread window deadlock".

--tml