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/
