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. > 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. > 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...) _______________________________________________ Kde-hardware-devel mailing list [email protected] https://mail.kde.org/mailman/listinfo/kde-hardware-devel
