dfaure added a comment.
The idea of the old code was: if I can't get the lock, then someone else is already in the process of starting kdeinit, so I'll just wait for that to happen, by locking again, i.e. blocking on purpose, and then checking that the DBus name is up, i.e. the other process did manage to do it successfully. I can't wrap my head around whatever the new code is trying to do instead. I said from the start that it wasn't tryLock() that was blocking but lock(), good to see that this is now confirmed, however we're back to square one: why is lock never returning? Surely the other process which is executing this method is releasing the lock after the QProcess::execute, right? REPOSITORY R271 KDBusAddons REVISION DETAIL https://phabricator.kde.org/D14302 To: jtamate, dfaure, #frameworks, thiago Cc: lvsouza, kde-frameworks-devel, michaelh, ngraham, bruns
