Re: Multi-threaded GTK+

[Tor Lillqvist <tml iki fi>]

Following up on myself:
 > 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).

I did some quick reading on related issues from the Google archives
and MSDN, and it doesn't look good. Without some major restructuring
in GDK-Win32, I don't think there is any chance that GTK+ would work,
in general, in a multi-threaded app, with different threds accessing
windows created by other threads. Some simple special cases might
work.

One problem is that each thread in Windows have its own message
queue. GDK-Win32 currently uses just one "message pump" in the main
thread. It will never see messages for windows created by other
threads.

Another problem is that various innocuous-looking GDI calls, like
MoveWindow, when invoked in another thread, in fact cause a message
being sent to the thread owning the window being operated on. "Send"
here means invoking the window's (actually window class's) window
procedure in the context of the window owner thread. That can only
happen when the window owner thread calls GetMessage or PeekMessage
next time. If the owning threads happens to be doing something else,
like waiting for the thread that calls MoveWindow, deadlock. Or
something like that.

One solution would be to, in a multi-threaded GTK+ application (one
that has called gdk_thread_init), have a single special thread created
by GDK-Win32. That thread would perform all window creation and such
GDI calls that cause messages to be sent. The other threads would send
user messages to the special thread telling it what to do.

I assume that pure graphics operations need not be handled by this
thread, but can be performed in any thread. Except that in that case,
there might be fun artifacts when the order of execution of GDI calls
gets scrambled, if some calls are delegated to the special thread,
while others are performed directly in any thread.

I wonder how other multi-thread-aware windowing toolkits for Windows
handle this. AWT presumably has had to solve the same problem?

Sigh.

--tml