KSyCoca, Thread safety, and Cache invalidation

Thiago Macieira thiago at kde.org
Tue Sep 15 04:49:26 BST 2015


On Sunday 13 September 2015 23:04:01 David Faure wrote:
> On Tuesday 14 July 2015 16:01:09 Thiago Macieira wrote:
> > If you need a machine-comparable time with other systems or across
> > reboots,
> > use QDateTime::currentDateTimeUtc(). That avoids refreshing the timezone
> > database to convert to local time.
> > 
> > Only use QDateTime::currentDateTime() if you want to show something to the
> > user. There's no other valid reason. (writing to a log counts as "showing
> > to the user")
> 
> What if I need to compare a file's modification time with a given timestamp?

File times are kept in UTC on disk.

> This code:
> 
>     qCDebug(SYCOCA) << "checking file timestamps";
>     const QDateTime stamp = QDateTime::fromMSecsSinceEpoch(timestamp);

You're using the function that creates a LocalTime timestamp and yet:

> ==24943==    by 0x573E8F7: QDateTime::operator<(QDateTime const&) const
> (qdatetime.cpp:3989)

Line 3989 indicates that one of the two isn't local time.

Something in your code does not match the helgrind trace.

> Should we have a QFileInfo::lastModifiedUtc()? Or to make this all much more
> intuitive, should there be a mutex in epochMSecsToLocalTime and
> localMSecsToEpochMSecs? [the same one, obviously]

What if we changed the existing lastModified() to return UTC? As I said, the 
date is stored in UTC already.

Though I imagine quite a few places don't convert to local time and would 
start showing UTC time unexpectedly...

-- 
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
   Software Architect - Intel Open Source Technology Center
      PGP/GPG: 0x6EF45358; fingerprint:
      E067 918B B660 DBD1 105C  966C 33F5 F005 6EF4 5358





More information about the kde-core-devel mailing list