KSyCoca, Thread safety, and Cache invalidation

[Vishesh Handa]

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>