KSyCoca, Thread safety, and Cache invalidation

Vishesh Handa me at vhanda.in
Fri Jun 19 21:00:09 BST 2015

On Sat, Jun 13, 2015 at 9:26 PM, David Faure <faure at kde.org> 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?

Vishesh Handa
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ksyscoca.patch
Type: text/x-patch
Size: 4782 bytes
Desc: not available
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20150619/36a709fc/attachment.bin>

More information about the kde-core-devel mailing list