[newui] [PATCH] Check that Gtk.main is not already running before starting another one

Vratislav Podzimek vpodzime at redhat.com
Tue Aug 7 09:27:23 UTC 2012


On Tue, 2012-08-07 at 11:15 +0200, Vratislav Podzimek wrote:
> On Mon, 2012-08-06 at 14:42 -0400, Chris Lumens wrote:
> > > > Seems a bit ungraceful, but at least there's a helpful comment.  The
> > > > best alternative I can suggest is joining on a thread but you'd have to
> > > > figure out which one to join on first.
> > > I believe we could use busy-wait here. Periodically (e.g. every 2
> > > seconds) test the Gtk.main_level() and when it falls to 0, run
> > > sys.exit(0). This way the exitHandler would be called at exit and we
> > > would not have to care about what thread crashed.
> > 
> > Yes, I guess you could do this.  I don't know that I like it over the
> > original code, though.
> The problem with the original code is, that exitHandler is not called.
> Using this way, sys.exit(0) is called from the main thread (which is the
> only case when it really works) and thus exits the installer in a clean
> way (running exitHandler). I don't see any problem in a busy-wait
> running check every 2 seconds in such "game over" situations.
> 
> > 
> > > Or we could write out the thread's name to a file in handleException,
> > > read it here and join the thread. Then run sys.exit(0). But this would
> > > be more complicated and I don't see any problem in a busy-wait in this
> > > case (exception appeared before UI started).
> > 
> > Yuck.  I'd definitely just prefer the original code to this.
> > 
> > One thing to keep in mind here is that we control the crashing behavior
> > of threads.  See AnacondaThread.run in threads.py.  So we can set flags
> > or signal other processes if we need to before running the exception
> > handler.
> Yeah, I know that and I looked at the code. But the problem is still the
> same. We could set some flag, so that our UI knows that python-meh is
> running and thus it is not a good idea to start new Gtk.main loop.
> However, I don't see any advantage of this compared to testing
> Gtk.main_level() (which is the thing we really care about).
> 
> Setting flag that python-meh is finished and anaconda should call
> sys.exit(0) means just a different busy-wait this time checking the
> flag. We cannot use GObject/DBus signal, because anaconda is not running
> Gtk.main loop. I've also tried using "good old unix signals", but
> handler gets just the signum and the frame [1] which cannot be easily
> used to run exitHandler. Moreover (just a thing I've learnt during
> testing), unix signals doesn't get handled within the Gtk.main loop in
> Python (which could be a problem -- try 'kill
> `cat /var/run/anaconda.pid`' from tty2 during installation).
> 
> So summed up, I see the way using Gtk.main_level()-checking busy-wait
> (calling sys.exit(0) from the main thread) as the best way. If anybody
> comes with a better solution (please bear in mind text mode with no
> Gtk.main loop and also exitHandler invocation), I will be glad to use
> it.
> 
Forgot to add the link:

[1] http://docs.python.org/library/signal.html#signal.signal

-- 
Vratislav Podzimek

Anaconda Rider | Red Hat, Inc. | Brno - Czech Republic



More information about the anaconda-patches mailing list