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
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ Kde-hardware-devel mailing list [email protected] https://mail.kde.org/mailman/listinfo/kde-hardware-devel
