<table><tr><td style="">dfaure added a comment.
</td><a style="text-decoration: none; padding: 4px 8px; margin: 0 8px 8px; float: right; color: #464C5C; font-weight: bold; border-radius: 3px; background-color: #F7F7F9; background-image: linear-gradient(to bottom,#fff,#f1f0f1); display: inline-block; border: 1px solid rgba(71,87,120,.2);" href="https://phabricator.kde.org/D14302">View Revision</a></tr></table><br /><div><div><p>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.</p>

<p>I can't wrap my head around whatever the new code is trying to do instead.</p>

<p>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?</p></div></div><br /><div><strong>REPOSITORY</strong><div><div>R271 KDBusAddons</div></div></div><br /><div><strong>REVISION DETAIL</strong><div><a href="https://phabricator.kde.org/D14302">https://phabricator.kde.org/D14302</a></div></div><br /><div><strong>To: </strong>jtamate, dfaure, Frameworks, thiago<br /><strong>Cc: </strong>lvsouza, kde-frameworks-devel, michaelh, ngraham, bruns<br /></div>