Amaury Forgeot d'Arc amaur...@gmail.com added the comment:
When using gtk and threads, it's necessary to call
gtk.gdk.threads_init()
--
nosy: +amaury.forgeotdarc
resolution: - works for me
status: open - closed
___
Python tracker
Antoine Pitrou pit...@free.fr added the comment:
Well I'm not a gtk user, but try to do something else than a print in
the timer. Perhaps gtk redirects all standard IO or something. It sounds
very strange that threads would stop working when gtk is imported.
--
Jean-Paul Calderone exar...@divmod.com added the comment:
pygtk doesn't release the GIL around its internal calls unless you call
threads_init. So I think this is pretty clearly just a misuse of the
pygtk library. There's nothing at all Python can do about it. If an
extension library doesn't
Antoine Pitrou pit...@free.fr added the comment:
It is probably a problem with the gtk/gobject Python binding.
By the way, you're supposed to call `gobject.threads_init()` if you use
threads with Python and gobject/gtk.
Besides, gtk certainly has its own timing facilities, while
threading.Timer
Eric e...@ericaro.net added the comment:
OK, this is a workaround.
adding this line
gtk.gdk.threads_init()
makes the job. And that's ok for me.
nevertheless, I still got the feeling that's this is a flaw in the Timer
implementation: it's behaviour is changed by some external (gtk) code.
New submission from Eric Atienza e...@ericaro.net:
this simple code:
import gtk
from threading import Timer
from time import sleep
def p():
print p
Timer(1, p).start()
#gtk.main()
sleep(10)
print done
does print p a second after it starts.
when I remove the comment of the gtk.main()
