On Monday 20 July 2015 16:05:06 David Faure wrote: > On Friday 26 June 2015 18:03:00 Frank Reininghaus wrote: > > https://bugs.kde.org/show_bug.cgi?id=346974 > > > > According to the backtrace, the process is busy inside > > QMimeDataBase::mimeTypeForName(QString) doing time-related things and > > accessing /etc/localtime all the time, probably because of the mtime > > check that you mentioned. I don't know that Qt version was used > > though, so I'm not sure if that still applies to the most recent > > versions. > > I forgot my own code, it seems. > Looking at it again: it does already only check the mtime on disk every 5 > seconds. > > int qmime_secondsBetweenChecks = 5; > bool QMimeProviderBase::shouldCheck() > { > const QDateTime now = QDateTime::currentDateTime(); > if (m_lastCheck.isValid() && m_lastCheck.secsTo(now) < > qmime_secondsBetweenChecks) return false; > m_lastCheck = now; > return true; > } > > But it's exactly that call to QDateTime::currentDateTime() which ends up > calling tzset (which seems to access to /etc/localtime on disk every time), > according to https://bugsfiles.kde.org/attachment.cgi?id=92719 > > Maybe this code should use QElapsedTimer instead of > QDateTime::currentDateTime()? Or maybe QDateTime::currentDateTime() could > avoid calling the awful tzset()? Thiago, any input?
Sorry, I had missed the other replies to this thread. (I recommend using k-f-d to discuss code in KF5, kde-core-devel has too much other stuff I have a hard time following it). I'll work on a Qt patch. -- David Faure, [email protected], http://www.davidfaure.fr Working on KDE Frameworks 5
