Hi James. My expertise in threads is almost exclusively being on the receiving end of a hang due to this sort of thing, and filing a bug to get someone like you to fix it. ;-)
Having said that.... I *think* you might be modifying the GUI outside of the main thread when you set the cancel button's state to insensitive in kill(). If I do this: gobject.idle_add(self.cancel_button.set_sensitive, False) I'm able to set the button's state without a hang. Does this help? --joanie On Wed, 2010-02-10 at 10:18 -0500, James Tatum wrote: > Hi all, > > I spent quite a while trying to figure out why I was the only one > seeing a hang with this bit of code[1]. Eventually I found a small > amount of the apparently long history of threading and at-spi/gail, > including bug 329454[2]. The code is threaded but only two threads > touch the UI - main and a thread to update the progress bar. All the > UI touching bits seem to be wrapped in the appropriate code for thread > entry/exit. I'm running at-spi 1.29.6. > > Honestly, I'm not even sure where to begin with this. pygtk handles > some of the unpleasantries of threading so it's unclear if the > threading sequence is happening exactly as documented in the bug > below. Has anyone experienced and resolved anything similar? > > [1] http://pastebin.com/f5b498ef5 > [2] https://bugzilla.gnome.org/show_bug.cgi?id=329454 > _______________________________________________ > gnome-accessibility-list mailing list > gnome-accessibility-list@gnome.org > http://mail.gnome.org/mailman/listinfo/gnome-accessibility-list _______________________________________________ gnome-accessibility-list mailing list gnome-accessibility-list@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-accessibility-list
