> 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.
Cheers,
Ivan
On 13 June 2015 at 04:04, Sebastian Kügler <se...@kde.org> wrote:
> On Saturday, June 13, 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.
> [...]
>> I'm not quite sure on how to go about this. Do you have any
>> suggestions? I'm leaning towards (3), but the locking code is scary.
>
> 7. the gui thread listens to dbus and sends a signal to the other threads?
> --
> sebas
>
> Sebastian Kügler | http://vizZzion.org | http://kde.org
>
--
Cheerio,
Ivan
--
While you were hanging yourself on someone else's words
Dying to believe in what you heard
I was staring straight into the shining sun
