[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