Re: Updating GUI during long operation

[Simon Feltman <s feltman gmail com>]

On Fri, Apr 26, 2013 at 6:16 AM, Colomban Wendling <
lists ban herbesfolles org> wrote:

> That's weird.  However, although I don't know much about Python
> threading (and another guy in this thread suggests it's not really
> good), I'm wondering whether your thread couldn't be simply locking
> stuff used by both GUI and worker thread, effectively blocking the GUI one.

To clarify, Python threading is probably the wrong tool for CPU bound
operations unless those operations free up the GIL.

On Fri, Apr 26, 2013 at 5:05 PM, Kip Warner <kip thevertigo com> wrote:

> Thanks Nicola. For some reason, and perhaps this is just coincidental,
> but I've noticed the GUI seems fully responsive since I exchanged
> GObject.idle_add() for Gdk.threads_add_idle()? I wonder why, or if
> that's just coincidental and my machine is just better behaved today for
> an unrelated reason.


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.

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.

-Simon