D14302: Don't block forever in ensureKdeinitRunning

[David Faure]

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-frameworks-devel/attachments/20180725/473423b6/attachment-0001.html>