fvogt added a comment.
Just a quick idea, it might be wrong: If you use a `QTimer` instead of `QElapsedTimer`, you can get rid of `nextTimeoutMsecs`. This would also simplify the logic a bit. INLINE COMMENTS > jtamate wrote in slavebase.cpp:279 > Reading the documentation http://doc.qt.io/qt-5/qelapsedtimer.html > I'm not able to say if start() will restart a timer or continue. My guess is > that it also restarts. > And also because calling restart() on a QElapsedTimer that is invalid results > in undefined behavior. This does not matter - previously this line guaranteed that this does not fire again until `nextTimeout` is set again. Now it will fire on the next `dispatchLoop()` call. You probably want to call `d->nextTimeout.invalidate()` here. > jtamate wrote in slavebase.cpp:1052 > | before | now | where > | > | next = now + timeout | msecs = timeout, (re)start elapsed | > setTimeoutSpecialCommand | > | if next < now then | if has elapsed timeout then | dispatchLoop > | > | > > I think both are equivalent. You probably want to call `invalidate` here as well and then not `start()` it in this case. REPOSITORY R241 KIO REVISION DETAIL https://phabricator.kde.org/D9983 To: jtamate, #frameworks, fvogt Cc: fvogt, ngraham
