Red Hat Bugzilla – Bug 213820
pirut doesn't update ui during long yum operations
Last modified: 2007-11-30 17:11:47 EST
Right now when running pirut, it blocks the UI while doing I/O. Previously the
solution for this was going to be to rely on the composition manager to make
invalidated regions automatically redraw. Now that we're using compiz, that's
not really a good idea (because compiz will slowly desaturate and fade out a
window that isn't responding to window manager pings, and because since we're
shipping compiz we'll always have to ship metacity without a compositor.
So I spent the last three days of train rides to and from work and the thursday
night hackfest today coming up with an initial patch to make things better.
It's not super-tested but it seems to mostly work.
Created attachment 140217 [details]
delegate blocking calls to helper threads
Created attachment 140218 [details]
convienence class to hide the murky details
you'll also need the above patch to rhpl for things to work
You know, I've been thinking about it a bit and maybe a better solution than
finishing up these patches would be to offload all the work to yum-updatesd.
That way even if the app crashes or X gets killed the update will continue and
not hose the database. So I think it would be something like yum-updatesd does
all the heavy lifting, pup just shows a view of yum-updatesd and pirut works as
a remote control into yum-updatesd as well as being a view itself.
Both pup and pirut would only make non-blocking d-bus calls to talk to the
updatesd daemon, so they would always properly redraw.
We should now update as much as is possible without either a) threading or b)
switching to multiple processes. Threading introduces some fun problems with
sqlite and multiple processes is a whole different ball game so neither is
immediately on the hit list.
If you hit places where we aren't refreshing, file specific bugs about them and
I'll see about making sure all the proper callbacks are occurring (and see about
adding more if needed)