GNOME Bugzilla – Bug 663068
pygmainloop: avoid lockups if multiple glib.MainLoop exist
Last modified: 2012-04-03 20:28:43 UTC
This patch fixes a problem that occurs if multiple glib.MainLoop objects exist. I'm not sure this is the be-all-and-end-all of trying to sort out the interaction (and the interaction with the GTK+ main loop), but it definitely makes things better for the case here where a signal is ignored at the Python level. The same problem occurs for pygobject2 and a trivial backport works. I'll attach a test case.
Created attachment 200304 [details] [review] pygmainloop: avoid lockups if multiple glib.MainLoop exist If multiple glib.MainLoop() sources exist, then we will add multiple watches, and when python writes a byte to the wakeup pipe, all of the sources will try to read it; only one will succeed and the others will block. Set both ends of the pipe nonblocking to avoid this.
Created attachment 200305 [details] Test case
This still doesn't work with Gtk.main() Not sure if this is a similar bug but when using Gtk.main and sending a SIGINT (ctrl-c) the app hangs. But if we use GLib.MainLoop().run() SIGINT does get caught and the app exits. We can't link to Gtk so we can't override Gtk.Main() to provide signal handing. Is there something similar we can do to fix that issue?
Comment on attachment 200304 [details] [review] pygmainloop: avoid lockups if multiple glib.MainLoop exist Could someone merge the test case into the test suite? Ideally there would be a single patch. Thanks!
Comment on attachment 200304 [details] [review] pygmainloop: avoid lockups if multiple glib.MainLoop exist This was already committed in October 2011.
I simplified your test case so that it avoids using ctypes and integrated it into the test suite: http://git.gnome.org/browse/pygobject/commit/?id=2a5a33a9c9c170830c98c2e32fa8dcea3c35f2e6 Thank you!