[Kde-hardware-devel] PowerManager Library

[Lamarque V. Souza]

Em Wednesday 20 June 2012, Daniel Nicoletti escreveu:
> 2012/6/20 Lamarque V. Souza <lamarque at kde.org>:
> >> My proposal is to use *cached* values.
> > 
> > The signal/slots part is also as important as using cached values.
> 
> Ok, I'm actually writing the patch now so you can see what I'm talking
> about, I thought about the two options I proposed and I think I know the
> best one.

	Ok.
 
> > Hmm now I am wondering why it does not always work:
> https://projects.kde.org/projects/extragear/base/networkmanagement/reposito
> ry/revisions/5d6050bf3e70930bfb80321f710613142c2db95a
> 
> Don't wonder again :D
> It's easy, error checking! It's again not fault of QDBusPendingReply,
> it's that if the interface is not available or any other kind of error
> happen you can't trust the returned value, if you change the above link to
> use QDBusPendingReply and do wait for finish you will have the _same_
> behavior. And IMO it's not only better to explicit shows what the
> class is doing but you also avoid another constructor.

	I changed it to QDBusReply, which is the equivalent to 
QDBusPendingReply+waitForFinished, and the crash is gone (the link above is a 
diff output showing thatt). The link in your last email states that 
QDBusPendingReply::value() does an implicit waitForFinished. The code in the 
link above is very old (probably more than three years old) and it used to 
work perfectly until some months ago when I received a crash report from 
bugs.kde.org. After reading the link you sent I am wondering why out of sudden 
QDBusPendingReply::value() stopped doing the implicit waitForFinished in 
Plasma NM? The interface is not invalid, if you read the rest of Plasma NM 
code you will notice that the cod above run only when the Plasma NM's kded 
module send the RemoteActivatableAdded signal, which indicates the DBus 
interface is available.
	 
> > 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.
> 
> The above comment explains your issue ;-)

	No, it does not.
 
> > 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.
> 
> Well you clearly need to see my patch to understand what I'm saying :P

	Probably.
 
> > 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.
> 
> You don't need to recycle them that's the point.

	Ok, so how do you use them if they are still invalid after the service 
is back to the bus?
 
> > 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.
> 
> Well, KDE startup would start faster if kded loaded things async, so fork()
> would run sooner. But this wouldn't reduce kded latency.

	Agreed.
 
> > 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.
> 
> Don't confuse things, I'm wasn't talking about the libsolid using threads
> on the code we are discussing, it just doesn't make any sense, I was
> talking about kded process using threads so calls don't block it.

	So why did you bring the kded latency problem to the talking? What was 
your pointing in doing that?

-- 
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/12033029/attachment.html>