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? -- David Faure, fa...@kde.org, http://www.davidfaure.fr Working on KDE Frameworks 5