[Kde-pim] Akonadi + multithreading

[Patrick Ohly]

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
...
Unable to register service as "org.freedesktop.Akonadi.Control.lock"
Maybe it's already running?
"[
0: /usr/bin/akonadi_control() [0x42f654]
1: /usr/bin/akonadi_control() [0x42f991]
2: /lib/x86_64-linux-gnu/libc.so.6(+0x324f0) [0x7ff4a26fb4f0]
3: /lib/x86_64-linux-gnu/libc.so.6(gsignal+0x35) [0x7ff4a26fb475]
4: /lib/x86_64-linux-gnu/libc.so.6(abort+0x180) [0x7ff4a26fe6f0]
5: /usr/lib/x86_64-linux-gnu/libQtCore.so.4(_Z17qt_message_output9QtMsgTypePKc+0x122) [0x7ff4a347d722]
6: /usr/bin/akonadi_control() [0x43183b]
7: /usr/lib/x86_64-linux-gnu/libQtCore.so.4(_ZN9QIODevice5writeEPKcx
+0xb4) [0x7ff4a3517944]
8: /usr/lib/x86_64-linux-gnu/libQtCore.so.4(+0x11c5ef) [0x7ff4a35225ef]
9: /usr/lib/x86_64-linux-gnu/libQtCore.so.4(_ZN11QTextStreamD1Ev+0x3b)
[0x7ff4a352abeb]
10: /usr/bin/akonadi_control() [0x40d35f]
11: /usr/bin/akonadi_control() [0x40998b]
12: /lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xfd)
[0x7ff4a26e7ead]
13: /usr/bin/akonadi_control() [0x409c61]
]
"

Then the test program just hangs.

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.

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?

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.

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/