KSyCoca, Thread safety, and Cache invalidation

[David Faure]

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, faure at kde.org, http://www.davidfaure.fr
Working on KDE Frameworks 5