KSyCoca, Thread safety, and Cache invalidation

David Faure faure at kde.org
Sat Jun 13 20:26:57 BST 2015

On Saturday 13 June 2015 02:04:03 Vishesh Handa wrote:
> 3. The gui thread on receiving the dbus signal updates its db as well
> as the database of all other threads. This is slightly complex and
> would require locking code similar to (2) since the other threads
> could be in the process of using KSycoca.

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).

David Faure, faure at kde.org, http://www.davidfaure.fr
Working on KDE Frameworks 5

More information about the kde-core-devel mailing list