Re: GTK and threads

[Tor Lillqvist <tml iki fi>]

kornelix writes:
> I hope you will indulge me. I don't recall any counterparts in
> Win32 to these wrapper functions (gtk/gdk init / enter / leave).
> Perhaps I am off base, but I think Win32 takes care of its own
> locking and threading business.

Well, surprise, as far as I know, it doesn't. For instance an utterly
trivial-looking Win32 API like SetWindowText() doesn't directly
manipulate the window's title. It sends a message to the thread that
owns (created) the window in question. If the window was created from
another thread, that doesn't have a message pump (isn't waiting to
handle Windows messages most of the time), but for instance is another
random "worker" thread that you just happened to create a window from,
you will have fun.

You don't need to google for long to find articles with statements
like:

    You get the assertions because MFC does not permit you to access
    most CWnd functions from a thread that did not create the window.
    The assertions are a warning that you are attempting an unsafe
    operation because the MFC message routing code is not thread safe.

And that is just an example, written by somebody who says he is a VC++
MVP, so presumably knows what he is talking about.

The article quoted above is from 2002, so of course, it might be that
I am completely wrong here, and that some very new MFC version
actually is all-singing all-dancing multi-thread-transparent where
user code can do anything it wants from any thread, like you say. On
the other hand, that doesn't seem likely, as MFC is much on its way
out, isn't it, considering the intended future with managed code,
Windows.Forms and whatnot?

> One of you mentioned that X11 has no thread awareness in its user 
> (caller) protocol. Sounds great to me. Was this a criticism?

No, on the contrary. I mentioned it as a comparison to the Win32
windowing and graphics API, which isn't based on a network protocol,
and where thread dependencies are very much built-in (which makes it
much harder for a toolkit running on top of it to support
multi-threadedness).

> Sadly this is the typical state of documentation for Linux and most 
> open-source software.

If you feel like that, it's great opportunity for you to help, isn't it?

--tml