Re: Xlib: unexpected async reply (sequence #####)!
On Sun, 2007-08-05 at 20:11 +0800, Gregory Hosler wrote: Your example clears up alot of stuff for me. One of my questions (that your example pretty much clarifies for me), was what do I g_idle_add() ? If I understand correctly, you basically add callback functions, and in particular, ones that are gtk/gdk related (i.e. that deal with the displaying of widgets). is this more or less correct ? Yes. The callback functions can contain chunks of widget manipulation code that you wish to run at some point when the main thread's main event loop becomes available. If you wish to run the code only once per g_idle_add(), you must return FALSE from the callback. so, um, when a g_idle_add does a gtk_widget_show() on a widget, and that widget would get displayed as part of the main thread. AFAIK, yes. Am I correct to say that things like gtk_label_new(), and all the related calls to build a label widget, can be done in a thread, but the show must be done in the main loop (via the g_adle_add() call) ? I would be more prudent than that. The process of creating widgets may involve retrieving font size information and stuff like that, so it'd best be done on the main thread. If there a list (or guideline) of which gtk_calls should be done in the idle, and which need not be ? I'd put them all on the main thread. In fact, I will go so far as to say that, if you were to compile only the code that's part of your side-thread(s), you shouldn't need gtk+ at all. HTH, Gabriel ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: Xlib: unexpected async reply (sequence #####)!
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 a lot of gtk withing my thread. Looks like it might be the way to go for me. Beware that you need to ensure that you call gdk_threads_enter() before calling gtk_main(). That _is_ stated in the docs' examples but it's not entirely obvious. I wrote about it in some detail here: http://research.operationaldynamics.com/blogs/andrew/software/gnome-desktop/gtk-thread-awareness.html AfC Sydney -- Andrew Frederick Cowie Managing Director Operational Dynamics Consulting, Pty Ltd Sydney+61 2 9977 6866 New York +1 646 472 5054 Toronto +1 647 477 5603 London+44 207 1019201 We are an operations engineering consultancy focusing on strategy, organizational architecture, systems review, and change management procedures: enabling successful use of open source in mission critical enterprises, worldwide. http://www.operationaldynamics.com/ ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: Xlib: unexpected async reply (sequence #####)!
On Sun, 2007-08-05 at 11:29 +0800, Gregory Hosler wrote:
I'm looking for code examples specifically on how to use/implement
g_idle_add().
Know any projects that uses g_idle_add() and related infrastructure?
static gboolean
make_insensitive_idle_cb(gpointer data)
{
GtkWidget *widget = GTK_WIDGET(data);
gtk_widget_set_sensitive(widget, FALSE);
/* Return FALSE so as not to keep executing this function over and over
again */
return FALSE;
}
static gpointer
my_thread(gpointer data)
{
/* ... do something of long duration, during which ... */
g_idle_add(make_insensitive_idle_cb, some_widget);
/* ... do the rest of the long duration stuff ... */
return NULL;
}
Have a look at
http://developer.gnome.org/doc/API/2.0/glib/glib-The-Main-Event-Loop.html#id2603517
HTH,
Gabriel
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: Xlib: unexpected async reply (sequence #####)!
On Sun, 2007-08-05 at 11:24 +0800, Gregory Hosler wrote: The main loop is already protected (by threads_enter()/threads_leave() so I didn't need to add any code at all to the main code (and I don't have any timeout callbacks either), so the only places I needed to add the threads_enter/leave was in the threads (2 small ones) themselves. That's fine, except that you will also need it in any handler called from the glib main loop, such as GIOChannel callbacks, child watch callbacks and any custom GSource objects that you attach to the main loop, where any of these call GDK/GTK+ functions. having said that... That is why using g_idle_add() is often a better approach. just looked at the man/devhelp page. Looks interesting. I'm looking for some code examples. actual working examples would be nice. All you need to do is have an idle handler returning FALSE which calls the GDK/GTK+ functions that you want to have executed from the calling thread. The only other point to remember is that you need to ensure that any data passed by reference via the data argument is still valid when the main loop executes the idle handler, which usually means that you need to allocate it on the heap and free it in the idle handler when you are finished with it. Chris ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: Xlib: unexpected async reply (sequence #####)!
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Gabriel Schulhof wrote:
On Sun, 2007-08-05 at 11:29 +0800, Gregory Hosler wrote:
I'm looking for code examples specifically on how to use/implement
g_idle_add().
Know any projects that uses g_idle_add() and related infrastructure?
static gboolean
make_insensitive_idle_cb(gpointer data)
{
GtkWidget *widget = GTK_WIDGET(data);
gtk_widget_set_sensitive(widget, FALSE);
/* Return FALSE so as not to keep executing this function over and over
again */
return FALSE;
}
static gpointer
my_thread(gpointer data)
{
/* ... do something of long duration, during which ... */
g_idle_add(make_insensitive_idle_cb, some_widget);
/* ... do the rest of the long duration stuff ... */
return NULL;
}
Have a look at
http://developer.gnome.org/doc/API/2.0/glib/glib-The-Main-Event-Loop.html#id2603517
I actually had a look at that page prior to my post. It didn't answer some of
the basic questions / concerns I had.
Your example clears up alot of stuff for me. One of my questions (that your
example pretty much clarifies for me), was what do I g_idle_add() ?
If I understand correctly, you basically add callback functions, and in
particular, ones that are gtk/gdk related (i.e. that deal with the displaying of
widgets).
is this more or less correct ?
so, um, when a g_idle_add does a gtk_widget_show() on a widget, and that
widget would get displayed as part of the main thread.
Am I correct to say that things like gtk_label_new(), and all the related calls
to build a label widget, can be done in a thread, but the show must be done in
the main loop (via the g_adle_add() call) ?
If there a list (or guideline) of which gtk_calls should be done in the idle,
and which need not be ?
many thanks,
- -Greg
HTH,
yes, it did!
- -G
Gabriel
- --
+-+
Please also check the log file at /dev/null for additional information.
(from /var/log/Xorg.setup.log)
| Greg Hosler [EMAIL PROTECTED]|
+-+
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.7 (GNU/Linux)
iD8DBQFGtb57404fl/0CV/QRAtJHAKCcPTvYTNlvKN71ttWyEGUTkuBd2ACcDmvx
eJuwrFcdbeHq0vHmnwBHets=
=S79l
-END PGP SIGNATURE-
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Xlib: unexpected async reply (sequence #####)!
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi all, I have a threaded gtk application. The threads create some gui (gtk widgets/windows). and most of the time (maybe 80%) everything works as expected. Occassionally I will get the message on stdout Xlib: unexpected async reply (sequence #)! the ### is an x event sequence number I am suspecting that this is because of the x calls from 2 different threads. Is this a known problem? Any way around this ? (I thought gtk was supposed to be thread ok :) gtk2-2.10.13-1.fc6 glib-1.2.10-26.fc6 libX11-1.0.3-7.fc6 (this is where that message is coming from :) many thanks for any hints, suggestions, pointers. - -Greg - -- +-+ Please also check the log file at /dev/null for additional information. (from /var/log/Xorg.setup.log) | Greg Hosler [EMAIL PROTECTED]| +-+ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (GNU/Linux) iD8DBQFGtIFP404fl/0CV/QRAvFCAJ42fbljJpIyKqNJjcFfYL5gsd6HhQCg4xYb OBIcTPUyn56XXYC8ZM4WKxo= =WJi+ -END PGP SIGNATURE- ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: Xlib: unexpected async reply (sequence #####)!
On Sat, Aug 04, 2007 at 09:38:25PM +0800, Gregory Hosler wrote: I have a threaded gtk application. The threads create some gui (gtk widgets/windows). and most of the time (maybe 80%) everything works as expected. Occassionally I will get the message on stdout Xlib: unexpected async reply (sequence #)! the ### is an x event sequence number I am suspecting that this is because of the x calls from 2 different threads. Is this a known problem? Any way around this ? (I thought gtk was supposed to be thread ok :) The answer depends on your defintions of `OK', `known' and `problem': - Gtk+ is thread-aware - Gtk+ is not thread-safe If you operate on the GUI from multiple threads: - you are responsible for the locking on Unix/X - it will just not work on MS Windows See http://developer.gnome.org/doc/API/2.0/gdk/gdk-Threads.html People typically operate on the GUI only from the main thread (i.e. running gtk_main()) and pass work requests to it via g_idle_add() or some other queue mechanism. This topic is discussed here every other week, see the list archives. Yeti -- http://gwyddion.net/ ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: Xlib: unexpected async reply (sequence #####)!
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 David Ne?as (Yeti) wrote: On Sat, Aug 04, 2007 at 09:38:25PM +0800, Gregory Hosler wrote: I have a threaded gtk application. The threads create some gui (gtk widgets/windows). and most of the time (maybe 80%) everything works as expected. Occassionally I will get the message on stdout Xlib: unexpected async reply (sequence #)! the ### is an x event sequence number I am suspecting that this is because of the x calls from 2 different threads. Is this a known problem? Any way around this ? (I thought gtk was supposed to be thread ok :) The answer depends on your defintions of `OK', `known' and `problem': - Gtk+ is thread-aware - Gtk+ is not thread-safe If you operate on the GUI from multiple threads: - you are responsible for the locking on Unix/X - it will just not work on MS Windows I'm only interested in X. Any tips/hints/pointers on locking X ? See http://developer.gnome.org/doc/API/2.0/gdk/gdk-Threads.html Thanks, I'll take a look. People typically operate on the GUI only from the main thread (i.e. running gtk_main()) and pass work requests to it via g_idle_add() or some other queue mechanism. This thought occured to me. It's not a lot of gui I have to manage, but managing it from a thread different from the one using it is a bit of a hassle. This topic is discussed here every other week, see the list archives. i CHECKED the archives. honest. I did a search on $SUBJECT, and came up blank. Maybe I need to broaden my search. Anyway, I'll look at the gdk-Threads doc. Thanks for that! Yeti -- http://gwyddion.net/ ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list - -- +-+ Please also check the log file at /dev/null for additional information. (from /var/log/Xorg.setup.log) | Greg Hosler [EMAIL PROTECTED]| +-+ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (GNU/Linux) iD8DBQFGtIbI404fl/0CV/QRAh43AKCHVFsMCv9D1nUABDxf3gimiLnzHwCfbQoY AH02w+3a7Gu/NKNAK5vmocc= =B/3Q -END PGP SIGNATURE- ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: Xlib: unexpected async reply (sequence #####)!
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 David Ne?as (Yeti) wrote: On Sat, Aug 04, 2007 at 09:38:25PM +0800, Gregory Hosler wrote: I have a threaded gtk application. The threads create some gui (gtk widgets/windows). and most of the time (maybe 80%) everything works as expected. Occassionally I will get the message on stdout Xlib: unexpected async reply (sequence #)! the ### is an x event sequence number I am suspecting that this is because of the x calls from 2 different threads. Is this a known problem? Any way around this ? (I thought gtk was supposed to be thread ok :) The answer depends on your defintions of `OK', `known' and `problem': - Gtk+ is thread-aware - Gtk+ is not thread-safe If you operate on the GUI from multiple threads: - you are responsible for the locking on Unix/X - it will just not work on MS Windows See http://developer.gnome.org/doc/API/2.0/gdk/gdk-Threads.html 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. thanks for the pointer! - -G People typically operate on the GUI only from the main thread (i.e. running gtk_main()) and pass work requests to it via g_idle_add() or some other queue mechanism. This topic is discussed here every other week, see the list archives. Yeti -- http://gwyddion.net/ ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list - -- +-+ Please also check the log file at /dev/null for additional information. (from /var/log/Xorg.setup.log) | Greg Hosler [EMAIL PROTECTED]| +-+ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (GNU/Linux) iD8DBQFGtIgy404fl/0CV/QRAjb8AKDcG5q92/8nh9/AzPUfO/gFc1I01ACfWq9i X2oqg4dOP2r8i/yCjCz+nOc= =IQs8 -END PGP SIGNATURE- ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: Xlib: unexpected async reply (sequence #####)!
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. Chris ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: Xlib: unexpected async reply (sequence #####)!
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 ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: Xlib: unexpected async reply (sequence #####)!
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 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. In reviewing things (after seeing your email, thanks!) indeed I missed the points / significance about g_idle_add(). 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. The main loop is already protected (by threads_enter()/threads_leave() so I didn't need to add any code at all to the main code (and I don't have any timeout callbacks either), so the only places I needed to add the threads_enter/leave was in the threads (2 small ones) themselves. having said that... That is why using g_idle_add() is often a better approach. just looked at the man/devhelp page. Looks interesting. I'm looking for some code examples. actual working examples would be nice. Anyone know of any projects that use this approach? Many thanks for the heads up and best rgds, - -Greg Chris - -- +-+ Please also check the log file at /dev/null for additional information. (from /var/log/Xorg.setup.log) | Greg Hosler [EMAIL PROTECTED]| +-+ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (GNU/Linux) iD8DBQFGtULR404fl/0CV/QRAp8MAKDiRn1Q3PZBJFOrgpOj/cpDE6j3HwCg2dCH HzJL4sKYwHkmUnx1fMkdCjg= =Yg7O -END PGP SIGNATURE- ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: Xlib: unexpected async reply (sequence #####)!
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Brian J. Tarricone wrote: 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) I'm looking for code examples specifically on how to use/implement g_idle_add(). Know any projects that uses g_idle_add() and related infrastructure? many thanks and best rgds, - -Greg 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 ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list - -- +-+ Please also check the log file at /dev/null for additional information. (from /var/log/Xorg.setup.log) | Greg Hosler [EMAIL PROTECTED]| +-+ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (GNU/Linux) iD8DBQFGtUQ0404fl/0CV/QRAsR0AJ41Hip4BSpqZ6ZM/twRTpc2pu2VcgCgqZ4B s7iby7yRfpQExU34xAn0psQ= =0w50 -END PGP SIGNATURE- ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
