https://bugs.kde.org/show_bug.cgi?id=392768
--- Comment #7 from Julien Goodwin <jgood...@studio442.com.au> --- TL;DR of Kevin's notes in 411047#c6: "We're apparently excessively calling QAbstractSocket::waitForReadyRead(msecs=1) in a loop which causes high CPU usage." ... This is called by ConnectionBackend::waitForIncomingTask which just passes down the timeout value from its caller. That caller is SlaveBase::dispatchLoop, which gets its value from: ms = qMax<int>(d->nextTimeout.elapsed() - d->nextTimeoutMsecs, 1); Which should be sane enough assuming nextTimeoutMsecs is non-zero (although personally I think the way the timeouts are done here is silly, a read if available with no wait would be far more sensible with any sleeping being higher up) nextTimeoutMsecs is only ever set if SlaveBase::setTimeoutSpecialCommand is called, otherwise it's zero; notably if setTimeoutSpecialCommand is called with *exactly* zero it gets set to 1000, positive inputs do the obvious, but negative (to cancel) do not do similarly. setTimeoutSpecialCommand is called from HTTPProtocol::httpClose & HTTPProtocol::httpCloseConnection So if somehow they're not called at the end of a request that would leak connections? -- You are receiving this mail because: You are watching all bug changes.
