[Kde-hardware-devel] Getting rid of synchronous and uncached accessors in Solid
Dario Freddi
drf54321 at gmail.com
Fri Jun 4 01:27:39 CEST 2010
Hello people,
Preamble: I am talking about power management here, and highlighting problems
related to the HAL backend, but it might apply as well to other parts which
use DBus extensively.
while reviewing Matthias' patch, I was quite astonished by the number of
synchronous DBus calls we actually have inside our code. Given that right now
I'm working on stuff which uses DBus extensively and learned a lot on how
doing things right, I think it's time to make our DBus code more efficient and
fail proof.
There are mainly two problems I see: synchronous calls for setters, which
might take a long time and are not fail proof, and uncached accessors for
getters, requesting a property over and over.
1. Getting rid of sync calls
Right now, every setter in Solid::Control returns a bool. This makes the call
itself synchronous, and notifies about its success or failure. However, there
are two problems with that:
* It's synchronous
* The error is never detailed
My solution is returning a KJob, just like suspension does. While it might
seem overkill at a first glance, consider that is the only way to fix both
shortcomings. Also, the HAL backend has some big code paths in setters (such
as brightness setting) which might well fit into a separate job.
2. Getting rid of uncached accessors
Every getter in HAL's S::C backend asks DBus synchronously for a property.
This is quite unefficient when we could:
* Cache all properties on creation with GetAllProperties
* Connect to PropertyModified signal to catch changes
* Return the cached value in every getter
The only shortcoming I see with this approach is that there is the possibility
that upon creating the device/manager, accessing a getter right after creation
might result in getting back an uncached value. We might circumvent this by
making the GetAllProperties call synchronous. While I don't like that, I think
it's still way better than the current status.
This is mostly for Solid::Control, but caching properties in Solid would be
great as well.
Thoughts, opinions? (Kevin I'm mostly looking at you)
--
-------------------
Dario Freddi
KDE Developer
GPG Key Signature: 511A9A3B
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
Url : http://mail.kde.org/pipermail/kde-hardware-devel/attachments/20100604/46c87654/attachment.sig
More information about the Kde-hardware-devel
mailing list