[issue6073] threading.Timer and gtk.main are not compatible
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 rep...@bugs.python.org http://bugs.python.org/issue6073 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6073] threading.Timer and gtk.main are not compatible
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. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue6073 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6073] threading.Timer and gtk.main are not compatible
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 release the GIL, no Python code can run concurrently with it. In this case, the extension API you've invoked is the Gtk main loop, which runs until you stop it, usually right before your gtk app exits. -- nosy: +exarkun ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue6073 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6073] threading.Timer and gtk.main are not compatible
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 is rather crude. -- nosy: +pitrou status: open - pending ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue6073 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6073] threading.Timer and gtk.main are not compatible
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. -- status: pending - open ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue6073 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6073] threading.Timer and gtk.main are not compatible
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() line: the p is never printed. It is very exposed, as Timer is a common tool to build a GUI therefore with the gtk.main() loop active. -- components: Library (Lib) messages: 88137 nosy: atienza severity: normal status: open title: threading.Timer and gtk.main are not compatible type: behavior versions: Python 2.6 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue6073 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
