[Kde-hardware-devel] PowerManager Library

[Lamarque V. Souza]

Em Wednesday 20 June 2012, Daniel Nicoletti escreveu:
> > 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 signal/slots part is also as important as using 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

	Hmm now I am wondering why it does not always work: 

https://projects.kde.org/projects/extragear/base/networkmanagement/repository/revisions/5d6050bf3e70930bfb80321f710613142c2db95a

> 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.

	As you can see by the link above it is not only nepomuk and Appear that 
do something similar to that. solid-networkstatus also does something similar, 
so does Solid::Networking::status() in kdelibs.
 
> > 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.

	Yes, I am blocking but only when the service appears on the bus, which 
hopefully happens only once during the KDE session, so it is a valid usage in 
my oppinion. What I do not like is repeatedly doing synchronous calls during 
the life time of the KDE session. Doing it only once during session 
initialization is ok, doing it several times is not, that is my point.
 
> > 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.

	I turned them into pointers to make it easier to get the vaules from the 
new interface. As far as I know there is no other way to recycle a 
QDBusAbstractInterface. Please, tell me if there is another way.
 
> > 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.

	kded is slow probably because it synchronously loads modules one by one. 
It can do it asynchronously instead, which would improve things. But I agree 
that with kded using threads can give us better performance than just using 
signal/slots because there are more work to do in parallel than in 
Solid::PowerManagement.

	In Solid::Powermanagement we are just updating booleans, that is very 
fast once we get the values regardless the number of cores or threads we have, 
loading a kded modules is heavier, so taking adavantage of the several cores 
in the CPU by using threads can greately improve things. Use the right tool 
for the job, threads are Ok if you can make the cores busy to improve 
throughput. For updating only three booleans like in Solid::PowerManagement 
case using threads will not be faster than using asynchronous calls.

-- 
Lamarque V. Souza
KDE's Network Management maintainer
http://planetkde.org/pt-br
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-hardware-devel/attachments/20120620/a735046a/attachment-0001.html>