Re: GTK and threads

[kornelix <kornelix yahoo de>]

OK, I see. That was illuminating, but not the whole story.

In Win32, you can send messages to a window to make it update from its 
paint() function in its owning thread, or you can write directly to it 
from another thread, if you have its handle. I went and found an old 
code fragment from a graphic application I wrote about 1995:
SelectObject(hDC,hColorBrush[ii]); // draw in color
PatBlt(hDC,ipx,ipy,xw,yw,PATCOPY);
hDC is a handle to a "device context", basically a window pointer. The 
above code runs in a thread that did not create the window. No explicit 
locks are evident. The point here was speed: screen updates were much 
faster this way compared to waiting for the paint() function to run 
after invalidating a portion of the window.

My memory of win32 is old but I think the above is correct. I am sure 
your points are also correct.

regards



Tor Lillqvist wrote:

> 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
>
> _______________________________________________
> gtk-app-devel-list mailing list
> gtk-app-devel-list gnome org
> http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
>
>