On Friday 19 June 2015 22:00:09 Vishesh Handa wrote: > On Sat, Jun 13, 2015 at 9:26 PM, David Faure <fa...@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?
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. This requires adding a check for whether ksycoca is uptodate before any use of ksycoca data, maybe this can be done in KServiceFactory::self() and similar (assuming nobody ever caches that value, but none of the code in kservice does AFAICS). By having the mtime in ksycoca, it'll be per-thread, and no threading-specific code will be required at all. This would be more in line with the long term plans for all this, too (which is exactly that: something that works more like shared-mime-info: a per- directory cache updated at install time and on demand if the mtime or the directory changed, and the way to notice that the cache changed is by noticing its own mtime changing). -- David Faure, fa...@kde.org, http://www.davidfaure.fr Working on KDE Frameworks 5
