[Kde-hardware-devel] PowerManager Library

[Lamarque V. Souza]

Em Wednesday 20 June 2012, Daniel Nicoletti escreveu:
> Patch done, tested, works pretty well
> https://git.reviewboard.kde.org/r/105310/
> 
> > 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.
> 
> Well I don't know the crash backtrace, so I can't tell what the problem is.

	The bug in question is this one: 
https://bugs.kde.org/show_bug.cgi?id=283241, it contains the crashlog and some 
other information.
 
> > Ok, so how do you use them if they are still invalid after the service is
> > back to the bus?
> 
> Well the interface is invalid while no app has registered it, after some
> app registers it you can access. I do this a lot on my apps.

	Well, that did not work for Solid::Networking::status() and solid-
networkstatus months ago, so I changed them to reallocate the QDBusInterface 
to solid-networkstatus, now it works. Maybe there is a latency somewhere in 
the QDBusInterface code.
 
> > So why did you bring the kded latency problem to the talking? What was
> > your pointing in doing that?
> 
> Because you mentioned the desktop-freeze problem which was also because of
> a dead lock between apper and nm, async solved the problem, but using
> threads would have solved too (which is why apper kded module now runs
> on a thread, colord-kde kded, and print-manager...)

	I mentioned desktop freezes in general, not that particular bug. Hmm I 
guess you created a thread that communicates with dbus and another that does 
the heavy work. Ok, that would be good approach to prevent kded modules from 
blocking kded. 

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