KSyCoca, Thread safety, and Cache invalidation

[Milian Wolff]

On Saturday 13 June 2015 08:59:57 Ivan Čukić wrote:
> > 7. the gui thread listens to dbus and sends a signal to the other threads?
> 
> It can not send signals since those are not loopy threads.
> 
> 
> There is no need for a lot of locking if you put one instance of
> KSycoca. You could do something like this (class names are not real :)
> ):
> 
> class MainThread {
>     std::shared_ptr<KSycoca> m_ksycoca;
> }
> 
> std::shared_ptr<KSycoca> MainThread::sycoca() {
>     {
>         lock_guard...
>         return m_ksyscoca
>     }
> }
> 
> updateSyCoca() {
>     // create a sycoca instance
>     auto tempKSycoca = std::make_shared...;
> 
>     // do whatever with tempKSycoca
> 
>     {
>         lock_guard...
>         std::swap(tempKSycoca, m_ksycoca);
>     }
> }
> 
> This way, all the currently queried runners will use the non-updated sycoca.
> 
> The main thread will update it, and when it is loaded, it will safely
> swap the two. Any runner that calls the MainThread::sycoca() after
> that will be using the updated version.
> 
> Locked code contains only very cheap operations - construction of a
> shared_ptr, not the containing class; and for swapping two
> shared_ptrs.

It must be a shared_ptr<const KSycoca>. And you will still get potentially 
expensive sycoca rebuilding when something happens, but I'm not sure how 
expensive this is.

Bye
-- 
Milian Wolff
mail at milianw.de
http://milianw.de
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20150614/fd5bfc4e/attachment.sig>