Bug 213820 - pirut doesn't update ui during long yum operations
pirut doesn't update ui during long yum operations
Status: CLOSED RAWHIDE
Product: Fedora
Classification: Fedora
Component: pirut (Show other bugs)
rawhide
All Linux
medium Severity medium
: ---
: ---
Assigned To: Jeremy Katz
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2006-11-03 01:45 EST by Ray Strode [halfline]
Modified: 2007-11-30 17:11 EST (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2007-09-11 14:23:16 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
delegate blocking calls to helper threads (8.87 KB, patch)
2006-11-03 01:45 EST, Ray Strode [halfline]
no flags Details | Diff
convienence class to hide the murky details (6.44 KB, patch)
2006-11-03 01:48 EST, Ray Strode [halfline]
no flags Details | Diff

  None (edit)
Description Ray Strode [halfline] 2006-11-03 01:45: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.
Comment 1 Ray Strode [halfline] 2006-11-03 01:45:47 EST
Created attachment 140217 [details]
delegate blocking calls to helper threads
Comment 2 Ray Strode [halfline] 2006-11-03 01:48:26 EST
Created attachment 140218 [details]
convienence class to hide the murky details

you'll also need the above patch to rhpl for things to work
Comment 3 Ray Strode [halfline] 2007-05-03 08:06:25 EDT
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.
Comment 4 Jeremy Katz 2007-09-11 14:23:16 EDT
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)

Note You need to log in before you can comment on or make changes to this bug.