D14302: Don't block forever in ensureKdeinitRunning

[David Faure]

dfaure added a comment.


  In D14302#298099 <https://phabricator.kde.org/D14302#298099>, @thiago wrote:
  
  > In D14302#297515 <https://phabricator.kde.org/D14302#297515>, @dfaure wrote:
  >
  > > 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.
  >
  >
  > It's Kind of silly to tryLock() then lock(). Why not just lock()? Was it the optimisation to avoid the D-Bus call? If so, a comment would be warranted.
  
  
  Yes: it would be kind of silly to check the dbus servicename, get the lock (because nobody else is doing this), and then check the dbus service name again, what chance did that have to suddenly pass?
  
  I think the new set of comments explains quite clearly the logic, now.
  
  > Anyway, one theory for why the lock file is still present: it's stale from a previous boot, but the PID is taken by some process in the current boot. This is fixed in Qt 5.11 by saving the boot ID (commit 772863355a0cf57a49e93608790dfd17c8fd82da). So question to @jtamate , what Qt version is this? Can you paste here the contents of the lock file itself, as well as what process (if any) the PID in that file points to.
  
  Good point.

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