On 2010-07-05 20:32, Jason Heeris wrote:
>    2. Any GTK interaction, such as emitting a signal from this new
> thread, must be either:
>        a. done via glib.idle_add (if I'm happy to let GTK do it
> whenever it next feels like it), -OR-
>        b. wrapped in gtk.gdk.threads_enter()/...leave(), -OR-
>        c. in a "with: gtk.gdk.lock:" block (equivalent to 2.b)

Something worth noting is that if you're targeting Windows then 2.a. is 
your *only* option. Calling GTK+ functions from any thread other than 
the main thread will lock up on Windows. The win32 api handles threads 
quite differently from X11 and GTK's abstraction doesn't work there.

I would also point out that "whenever it next feels like it" is almost 
always going to be the same as "right away" unless you're doing 
something yourself that still blocks the main thread. If you don't want 
your processing thread to continue running while the idle handler gets 
queued and processes it's pretty easy to wait for it. Untested code:

def idle_add_and_wait(func, *args):
     event = threading.Event()
     def idle():
         try:
             func(*args)
             return False
         finally:
             event.set()
     gobject.idle_add(idle)
     event.wait()

-- 
Tim Evans
Applied Research Associates NZ
http://www.aranz.com/
_______________________________________________
pygtk mailing list   pygtk@daa.com.au
http://www.daa.com.au/mailman/listinfo/pygtk
Read the PyGTK FAQ: http://faq.pygtk.org/

Reply via email to