Merge lp:~nafai/gwibber/gnomekeyring-fix into lp:gwibber
Status: | Merged |
---|---|
Merged at revision: | not available |
Proposed branch: | lp:~nafai/gwibber/gnomekeyring-fix |
Merge into: | lp:gwibber |
Diff against target: |
187 lines (+75/-18) 4 files modified
bin/gwibber-service (+1/-3) gwibber/accounts.py (+0/-1) gwibber/microblog/dispatcher.py (+25/-14) gwibber/microblog/util/keyring.py (+49/-0) |
To merge this branch: | bzr merge lp:~nafai/gwibber/gnomekeyring-fix |
Related bugs: |
Reviewer | Review Type | Date Requested | Status |
---|---|---|---|
Martin Pitt | Pending | ||
James W | Pending | ||
Ken VanDine | Pending | ||
Review via email: mp+22994@code.launchpad.net |
Description of the change
This is a proposed fix for bug #554005.
Since accessing Gnome Keyring from threads causes a spike in CPU
usage, I have moved the access to gnome-keyring to the start of
gwibber-service, before threads are started. This section loads the
passwords from the keyring into a dictionary and then provides a
method for lookup. Then the calls to gnomekeyring are replaced with a
call to that method.
This patch handles the CPU pegging problem, but isn't a complete fix.
The following needs still to be done:
1) pitti proposed that the memory where this is stored should be
mlock()'d. He suggested we use ctypes to wrap the calls to mlock
and munlock. I've included stub functions, and pitti indicated he
could help with wrapping this.
2) This implementation only reads the accounts and their passwords at
the beginning of gwibber-service. The previous implementation
caught changes to the passwords as well as the addition and removal
of accounts by whenever actions are taken. Code still needs to be
added to handle this. There are a couple of options that I can
think of:
a) Start and restart the gwibber service when these changes are
made (in gwibber/
are unforseen problems with this -- for example,
gwibber-
How does the main gwibber process handle loosing the gwibber
service connection?
b) Add a method to the com.Gwibber.
updating or adding account information (id and password). This
method would then call a function we could add to
gwibber.
The problem I see with this is that other developers who may
look at the dbus services may assume this actually changes the
passwords, not just the in-memory data structure.
I imagine either of these options shouldn't be too hard to
implement. I'm hoping that Ken or someone else can find a quick
way to do this.
Good work, I'll look in more detail in the morning. Since gwibber-service is dbus activated, we could just make gwibber-accounts call the Quit method on the dispatcher and then before exiting itself start it back up via dbus. Before doing this, it should actually verify it was running.