Merge lp:~gerboland/unity8/async-dbus-dashcomm into lp:unity8
Status: | Merged |
---|---|
Approved by: | Michael Zanetti |
Approved revision: | 1523 |
Merged at revision: | 1546 |
Proposed branch: | lp:~gerboland/unity8/async-dbus-dashcomm |
Merge into: | lp:unity8 |
Diff against target: |
187 lines (+64/-14) 4 files modified
plugins/Unity/DashCommunicator/dashconnection.cpp (+30/-0) plugins/Unity/DashCommunicator/dashconnection.h (+4/-1) src/libunity8-private/abstractdbusservicemonitor.cpp (+21/-8) src/libunity8-private/abstractdbusservicemonitor.h (+9/-5) |
To merge this branch: | bzr merge lp:~gerboland/unity8/async-dbus-dashcomm |
Related bugs: |
Reviewer | Review Type | Date Requested | Status |
---|---|---|---|
Michael Zanetti (community) | Approve | ||
PS Jenkins bot (community) | continuous-integration | Needs Fixing | |
Review via email:
|
Commit message
DashCommunicator: replace QDBusInterface with a non-blocking simplification which does not introspect the service on creation
Description of the change
QDBusInterface on creation introspects the service it is pointed to. This introspection is performed on the GUI thread, no matter what thread QDBusInterface is created on - see the moveToThread in qtbase/
Therefore should the service being introspected is busy at the time, the GUI thread is blocked, which is a bad thing. This isn't too easily noticed today with unity8 on startup, but it is there (Greeter not reacting quickly).
It is much easier to notice if you ssh into the phone and do "stop unity8-dash; start unity-dash" and just watch the spinner as dash is starting. It can be seen to hang for 500ms+ - that's the entire shell GUI blocked for over 1/2 a second.
What do we loose not using QDbusInterface directly? Mainly the ability to connect to dbus signals from the service. QDbusInterface creates a meta object which represents the service's interface, and translates meta object calls to dbus calls. As DashCommunicator just calls dbus methods, this can be handled without any meta object bits, so the QDBusAbstractIn
* Are there any related MPs required for this MP to build/function as expected? Please list.
N
* Did you perform an exploratory manual test run of your code change and any related functionality?
Y on N7 & desktop
* Did you make sure that your branch does not contain spurious tags?
Y
* If you changed the packaging (debian), did you subscribe the ubuntu-unity team to this MP?
N/A
* If you changed the UI, has there been a design review?
N/A
PASSED: Continuous integration, rev:1522 jenkins. qa.ubuntu. com/job/ unity8- ci/5059/ jenkins. qa.ubuntu. com/job/ generic- deb-autopilot- vivid-touch/ 614 jenkins. qa.ubuntu. com/job/ unity-phablet- qmluitests- vivid/223 jenkins. qa.ubuntu. com/job/ unity8- vivid-amd64- ci/224 jenkins. qa.ubuntu. com/job/ unity8- vivid-i386- ci/224 jenkins. qa.ubuntu. com/job/ generic- deb-autopilot- runner- vivid-mako/ 527 jenkins. qa.ubuntu. com/job/ generic- mediumtests- builder- vivid-armhf/ 612 jenkins. qa.ubuntu. com/job/ generic- mediumtests- builder- vivid-armhf/ 612/artifact/ work/output/ *zip*/output. zip s-jenkins. ubuntu- ci:8080/ job/touch- flash-device/ 16665
http://
Executed test runs:
SUCCESS: http://
SUCCESS: http://
SUCCESS: http://
SUCCESS: http://
SUCCESS: http://
SUCCESS: http://
deb: http://
SUCCESS: http://
Click here to trigger a rebuild: s-jenkins. ubuntu- ci:8080/ job/unity8- ci/5059/ rebuild
http://