[Kde-hardware-devel] PowerManager Library

[Daniel Nicoletti]

> They may be less expensive but I still prefer to cache the value and use
> signals/slots to update it, that is more guaranteed not to cause freeze
> problems.
My proposal is to use *cached* values.

> The current behaviour is different because in some places Solid is using
> asynchronous calls as if it they were synchronous, which is wrong and we are
> lucky they are not causing nastty bugs so far. I still wonder why most of
> the time QDBusPendingReply::value() returns the correct value in the next
> line of the source code like QDBusReply::value() does. The calls below are
> all asynchornous (they return QDBusPendingReply) and we are using their
> values without checking for isValid(). We are lucky almost all the time they
> are valid:
You don't need to wonder just read:
http://qt-project.org/doc/qt-5.0/qdbuspendingreply.html#value
We need error checking not avoid QDBusPendingReply. And we are not
lucky, Lukas searched and only Apper and nepomuk use that and Apper
had it disabled due to wrong returned value.

> QDBusReply is the same thing as QDBusPendingReply + waitForFinished, just
> shorter :-):
So you are still blocking things, and shorter doesn't mean "safer" as
you stated, people not knowing the class will just think they found the bug.

> That is exactly what my patch does. managerIface, policyAgentIface and
> inhibitIface are no longer valid when their assolicated DBus service
> disappear from the bus. When services come back those objects are still
> invalid and need to be re-allocated, so basically my patch does a cold plug
> initialization everytime the services appear on the bus.
No, your patch makes all interfaces become pointers so that you delete
and new on them which is uneeded. What is needed it to get all the
values from the new interface.

> Sorry, by threads are not the answer for everything and they are not easy to
> debug. Anyway, the desktop freezes I am seeing in some places are indeed
> caused by synchronous calls, using the asynchronous API is enough to prevent
> them.
If threads are hard to debug you are using them wrong, KDE startup is
partially slow because kded doesn't use threads on their modules. Hence
it takes 3 seconds till it fork() on hot cache.