On Fri, 2013-04-26 at 20:22 -0700, Simon Feltman wrote: > To clarify, Python threading is probably the wrong tool for CPU bou d > operations unless those operations free up the GIL.
This might be, but ideally this is really something the designers of the various interpreters should be more concerned with than the user of the language. But I understand what you are saying. > Unless the GDK/GTK calls within the callback scheduled by > GObject.idle_add are explicitly surrounded with > Gdk.threads_enter/leave() along with a call Gdk.threads_init() at > program start, then chances are the problems you ran into are related > to GDK/GTK calls not being thread safe and the callback not holding > the GDK global lock. As Nicola mentioned, Gdk.threads_add_idle does > this for you. Also note that Gdk.threads_enter/leave are essentially > no-ops unless Gdk.threads_init is called. It makes sense since Gdk.threads_add_idle() is higher level than a GObject interface. > My confusion regarding these APIs stems from some of them being marked > as deprecated since version 3.6 (Gdk.threads_init and > Gdk.threads_enter/leave). In this case it is unclear whether or not > Gdk.threads_init is still necessary when using Gdk.threads_add_idle > with GTK+ >= 3.6. I think the safe thing to do if one isn't absolutely certain of the specific runtime version the user will be relying on and the documentation is still ambiguous or inconsistent, depending on where you are looking, is to just call both GObject.threads_init() and Gdk.threads_init() for good measure. Thanks for your help, Simon. -- Kip Warner -- Software Engineer OpenPGP encrypted/signed mail preferred http://www.thevertigo.com _______________________________________________ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
