KSyCoca, Thread safety, and Cache invalidation

[Frank Reininghaus]

Hi,

2015-06-21 16:54 GMT+02:00 David Faure:
> On Friday 19 June 2015 22:00:09 Vishesh Handa wrote:
>> On Sat, Jun 13, 2015 at 9:26 PM, David Faure wrote:
>> > 3 bis:
>> > I assume the threads without an event loop have some way to get tasks,
>> > right? So when the gui thread gets notified about ksycoca changes, it
>> > should post a task to these threads-with-no-eventloop which says "sycoca
>> > has changed". It's ok if they keep using an old instance meanwhile (the
>> > mmap'ed file uses refcounting in the kernel).
>> > When the thread finally gets the task it can call
>> > KSycoca::notifyDatabaseChanged  (it's a private slot, use
>> > QMetaObject::invokeMethod for now, if it works we can make it public).
>>
>> I've tried a hackish way to communicate with the other threads. See
>> attached patch.
>>
>> This doesn't quite work since KSysCocaPrivate::checkDatabase isn't
>> always called before finding an entry. Resetting the db in findEntry
>> leads of crashes cause the state of the stream isn't as expected by
>> the factory.
>>
>> Any tips?
>
> I thought about it again, and there's a much simpler solution.
> We get rid of dbus notification altogether, and we simply close+reopen the
> database if its mtime changed. This is how things work for shared-mime-info
> (QMimeDatabase) and it's much simpler.

checking the mtime frequently can have a bad effect on the performance
though if it's done incorrectly. There is a bug report about high CPU
usage in Dolphin if "sort by type" is used:

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 cannot quite reproduce the problem though because there are other
parts of Qt's mime type handling which keep my CPU even more busy than
the time check. I should check if this still happens in recent git
snapshots of Qt and try to investigate this further...)

Cheers,
Frank