KSyCoca, Thread safety, and Cache invalidation

[David Faure]

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