using KDBusConnectionPool in libraries

[Kevin Krammer]

On Friday, 2014-02-21, 08:30:02, Kevin Ottens wrote:
> Hello,
> 
> On Thursday 20 February 2014 20:03:20 Aaron J. Seigo wrote:
> > I ran into an interesting situation the other day with libkactivities: it
> > uses KDBusConnectionPool to create connections in a thread-safe manner.
> > KDBusConnectionPool creates a connection in whatever thread it happens to
> > be executed from. In libkactivities this creates a problem as a singleton
> > that is internal to the library uses KDBusConnectionPool .. so whatever
> > thread it happens to be called from first: that’s the thread it gets its
> > QDBusConnection object put into.
> 
> Well, isn't the problem that this singleton should be thread-safe or thread-
> local in the first place?

While this particular issue was triggered by D-Bus usage, I think any 
singleton that is intended to be used by multiple threads and has some of its 
functionality depend on event processing, needs to be aware of per-thread 
event loops.

> > Or, I suppose, we could invent a policy that applications should do all
> > dbus related activities in a specific thread .. though that can be
> > difficult to know as dbus calls are often hidden within libraries.
> > 
> > .. or, does anyone have a pointer to what exactly in QDBusConnection is
> > not
> > thread safe?
> 
> It wasn't (Qt4 times)... I have no idea if that's still the case today. It
> could be that this class isn't needed anymore.
> 
> As for what exactly is not thread safe in QDBusConnection I don't remember.
> Since it was highlighted by Nepomuk at the time and forced upon us by its
> API (almost behind us too) Vishesh or Sebastian should know more (adding
> them in CC).

I think some of the people who were working on the inital Kontact Touch also 
ran into this at some point, when trying to fit several agents into one 
process, each running in a different thread.

My guess is that it is thread-safe for sending, i.e. messages won't be 
interleaved, but there always needs to be a thread that runs the event loop 
for receiving and it is probably also the one that gets all replies and 
incoming calls.

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-frameworks-devel/attachments/20140221/6a2c116c/attachment.sig>