[Kde-pim] Akonadi + multithreading

[Kevin Krammer]

On Wednesday, 2014-03-12, 11:15:09, Patrick Ohly wrote:
> On Mon, 2014-03-10 at 14:24 +0100, Kevin Krammer wrote:
> > On Monday, 2014-03-10, 11:47:23, Patrick Ohly wrote:
> > > On Fri, 2014-03-07 at 17:55 +0100, Kevin Krammer wrote:
> > > > On Friday, 2014-03-07, 16:40:09, Patrick Ohly wrote:
> > > > > If I move the check into the main thread, will the other Akonadi
> > > > > methods
> > > > > (in particular Job::exec) work in background threads?
> > > > 
> > > > Yes. All thread's have their own default session, i.e. the
> > > > Akonadi::Sesssion::defaultSession() instance is a "per-thread
> > > > singleton".
> > > 
> > > Okay, I'll try it. One other potential pitfall is that the background
> > > thread creates the Akonadi::Collection which then later gets used for
> > > other operations in the main thread. But it sounds like that this
> > > shouldn't be a problem.
> > 
> > Right. Collection is a "value type" class, so as long as you are not
> > modifying it from two threads it should be fine.
> 
> Unfortunately it doesn't work. The root cause is that the worker thread
> is not created as a QThread. This probably also prevented
> Akonadi::ServerManager from working correctly. I must have overlooked
> the error messages related to that earlier.
> 
> A simpler test program fails more obviously:
> 
> QSocketNotifier: Can only be used with threads started with QThread
> QSocketNotifier: Can only be used with threads started with QThread
> QObject::startTimer: QTimer can only be used with threads started with
> QThread ...

Ah, yes. All those require an event loop, which requires an event dispatcher, 
which is created by QThread.
I had kind of assume that to be the case here, sorry :-/

> Right now, the thread gets created with glib, because that is the common
> baseline that SyncEvolution uses for KDE and GNOME. libakonadi-kde.so
> depends on it, at least how KDE/Qt were compiled in Debian.

The GLib support only means that the event dispatchers are capable of 
processing GLib event sources.

> Can anyone think of a way to make Akonadi work in "normal" threads?
> Perhaps whatever initialization QThread does in the new thread can be
> done after creating the thread differently?

I had a quick look but it doesn't look to be accessible through public API. 
Which makes sense since it is highly platform specific.

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

Cheers,
Kevin
-- 
Kevin Krammer, KDE developer, xdg-utils developer
KDE user support, developer mentoring
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 190 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-pim/attachments/20140312/8e5cf255/attachment.sig>
-------------- next part --------------
_______________________________________________
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/