Re: gdk threads ...

[Stef Walter <stefw gnome org>]

On 05/21/2012 04:18 PM, Paul Davis wrote:
> On Mon, May 21, 2012 at 9:39 AM, Michael Meeks
<michael meeks suse com> wrote:
> >            That claim sounds really strange; since - well - we do that in
> >     LibreOffice ourselves :-) 
> > 
> 
> Windows does not allow you to process events/messages for a given window
> in anything other than the thread that created the window. If you try to
> do this, you will either crash or cause memory corruption.

Michael, it may just happen that the GTK calls you've seen being
performed from arbitrary threads in LibreOffice don't result in Win32
event processing and/or window creation, and just update GTK state
internally or result in simple Win32 messages being posted.

But yes, on Win32 stuff breaks (pretty much immediately) when you call
the win32 APIs CreateWindow (or friends) and GetMessage (or friends, the
loop APIs) on the same window from another thread than the one that
created it. [1]

Even if you get the locking "right" -- even if absolutely only one
thread is executing at once in your process -- like Paul said, you still
get behavior that at a minimum freezes your window, and in other cases
can act a lot like memory corruption.

Each Win32 window is 'owned' by a thread, the one that created it, and
must have its message loop run on that same thread. That's been a mantra
of Win32 development for as long as I can remember. Especially during
the COM days. Many of the wild threading models that COM had were a
result of this Win32 limitation.

I have direct experience with this. When porting a GTK+ application to
Windows, I had to move from "cooperative threading" (ie: big lock) to
Win32 fibers (sorta like getcontext/setcontext) to get around this
problem. In either case I was only running one stack at once. But
running the stacks in different threads broke stuff on Win32. They had
to run in the same kernel thread.

Cheers,

Stef

[1] http://support.microsoft.com/kb/90975