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