Another thing to note about threads and PyGObject: I recently found that you must also call "GObject.threads_init()" to enable threading in the bindings. This is a bit of a misnomer because it is not related to GLib/GObject, but rather it sets up internal stuff in the bindings. There is also a ticket to get rid of this requirement: https://bugzilla.gnome.org/show_bug.cgi?id=686914
-Simon On Wed, Mar 6, 2013 at 1:24 AM, Jonathan Ballet <j...@multani.info> wrote: > Hi Simon, > > > On 03/02/2013 01:37 PM, Simon Feltman wrote: > >> >> Hey, >> >> On Sat, Mar 2, 2013 at 2:54 AM, Jonathan Ballet <j...@multani.info >> <mailto:j...@multani.info>> wrote: >> >> Re: Clarification of GTK/GDK locking pre GTK 4.0 >> http://thread.gmane.org/gmane.**__comp.gnome.gtk+.general/** >> 24817/__focus=24834<http://thread.gmane.org/gmane.__comp.gnome.gtk+.general/24817/__focus=24834> >> >> <http://thread.gmane.org/**gmane.comp.gnome.gtk+.general/** >> 24817/focus=24834<http://thread.gmane.org/gmane.comp.gnome.gtk+.general/24817/focus=24834> >> > >> >> >> Eh. >> I've been reading the whole thread, as well as other threads on the >> group, and I'm not sure the situation is clarified in my head... :-) >> Some says Gdk.thread_* functions are deprecated and everything >> touching Gtk should run in the main thread, some says GLib.idle_add >> is running in the main thread and it's OK but maybe not... >> >> >> I think I was able to gain a some understanding from that discussion. >> What I got from it is the deprecation is only for >> gdk_threads_enter/leave, not threading functions in general. Instead of >> using enter/leave, use gdk_threads_add_* functions to queue up a >> callbacks that interact with GTK/GDK. Internally these just wrap your >> callback in enter/leave anyhow. And enter/leave won't go away until GTK >> 4, they will always remain functional for the lifetime of GTK 3. >> >> All of this seems somewhat irrelevant at least in the current state of >> the code base if you are writing a single threaded app. So unless you >> want to intact with GTK from a thread other than the main one, you never >> need to call gdk_threads_init. And if you don't call gdk_threads_init, >> gdk_threads_enter/leave are a no-op anyway and a lock is not even used. >> >> ... > > >> > GLib.idle_add(gtk_entry.set_**text, "foo bar") >> > > > >> If GDK threading is enabled, I think it should be: >> Gdk.threads_add_idle(GLib.**PRIORITY_DEFAULT, gtk_entry.set_text, "foo >> bar") >> > > OK, so my plan will be to remove all the threads from the application, > except one I think (which does background download of URLs - although I'm > looking towards GIO to do this - it's not supposed to touch any Gtk related > things, I'll double check anyway). There are interesting parts where the > threads are not really required if Gtk is properly used. > > Then, I should be able to remove the Gdk.threads_* related functions and > hopefully to remove all the GLib.idle_add function calls described above > (which should simplify the code). > > Hopefully, I grasp the Gtk's threading model better now... > > Thanks for your help! > > Jonathan > > ______________________________**_________________ > python-hackers-list mailing list > python-hackers-list@gnome.org > https://mail.gnome.org/**mailman/listinfo/python-**hackers-list<https://mail.gnome.org/mailman/listinfo/python-hackers-list> >
_______________________________________________ python-hackers-list mailing list python-hackers-list@gnome.org https://mail.gnome.org/mailman/listinfo/python-hackers-list
