[Date Prev][Date Next] [Thread Prev][Thread Next]
[Thread Index]
[Date Index]
[Author Index]
Re: Xlib: unexpected async reply (sequence #####)!
- From: "Brian J. Tarricone" <bjt23 cornell edu>
- To: gtk-app-devel-list gnome org
- Subject: Re: Xlib: unexpected async reply (sequence #####)!
- Date: Sat, 4 Aug 2007 17:35:58 -0700
On Sat, 04 Aug 2007 22:50:06 +0100 Chris Vine wrote:
> On Sat, 2007-08-04 at 22:07 +0800, Gregory Hosler wrote:
> > That threads_enter/threads_leave doesn't look so bad, since I'm not
> > doing alot of gtk withing my thread. Looks like it might be the way
> > to go for me.
>
> You may be missing the point. If you access GTK+ from more than one
> thread, then all operations with GTK+ need to protected with the GDK
> lock, in any thread, including in the main GUI thread. That is why
> using g_idle_add() is often a better approach.
Well, not really. All gtk/gdk calls in the non-main thread need to be
protected, and also calls in the main thread that are done from an
idle or timeout function. Calls in the main thread from a gtk signal
handler don't need to be protected as they're called within the gdk
lock already. You also need to wrap gtk_main() in the main thread with
gdk_threads_enter()/_leave().
If you use the approach of always making gtk/gdk calls from the main
thread (by calling g_idle_add() from other threads), then you shouldn't
use gdk_threads_enter()/_leave() at all, and indeed shouldn't even call
gdk_threads_init(). This is still, IMHO, the easier and more reliable
approach (and will work on win32 as well as x11, whereas the above
approach will not).
-brian
[Date Prev][Date Next] [Thread Prev][Thread Next]
[Thread Index]
[Date Index]
[Author Index]