[Kde-pim] Akonadi + multithreading

[Patrick Ohly]

On Wed, 2014-03-12 at 12:01 +0100, Kevin Krammer wrote:
> On Wednesday, 2014-03-12, 11:15:09, Patrick Ohly wrote:
> > Using QThread to create the thread is the obvious solution, but it would
> > introduce a dependency on Qt in core SyncEvolution, which is not
> > desirable.
> 
> The code that accesses all the Akonadi API is already dependent on Qt, no?
> 
> I assume you have some kind of function that is executed by the thread and 
> works a bit like main(), i.e. when it returns it ends the thread.
> 
> If that is the case you could try something similar to main(), i.e. create a 
> QCoreApplication instance, any worker object and then call app.exec().
> Of course that implies that no other thread in the process creates such an 
> instance but that sounds like a safe assumption for SyncEvolution.

No, that won't work. First of all, not all of the SyncEvolution Akonadi
backend code runs in that thread. It's only the initial setup phase in
HTTP server mode which runs multithreaded, because that phase can take a
long time in other backends and cause timeouts in clients if not handled
carefully. Later, the same instance of the backend also gets called in
the main thread.

Furthermore, there's also KWallet support in SyncEvolution which runs
independently of the Akonadi backend in the main thread.

The workaround that I am using now is to shift the Akonadi operations
from the worker thread back to the main thread using GLib thread
synchronization primitives. That way the logic for backend
initialization can stay in a thread and other backends with longer
initialization time do not block the main thread, while Akonadi works
again.

It's not particularly nice code, but seems like the least evil solution.

Bye, Patrick



_______________________________________________
KDE PIM mailing list kde-pim at kde.org
https://mail.kde.org/mailman/listinfo/kde-pim
KDE PIM home page at http://pim.kde.org/