using KDBusConnectionPool in libraries

[Aaron J. Seigo]

On Friday, February 21, 2014 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?

Thread local is not really an option (as explained in my original email, there 
is no guarantee that the thread the object is created in continues to exist or 
even has an event loop in it).

Thread safe and always living in the main app thread would be an option, 
however. Or living in its own thread, but I’d reserve that for functionality 
that is blocking (processing intensive, relies on synchronous calls, etc.) and 
which would be vital enough to an application’s value that it justifies another 
thread in the system.

> > Of course, if that thread has no event loop and/or exits, then things stop
> > working as expected. In the case of libkactivities, things just stop
> > working, period.
> > 
> > Either a better solution needs to be found for KDBusConnectionPool or a
> > warning should be placed prominently in the apidox about this “gotcha” 
and
> > perhaps it should be completely avoided in other frameworks where it is
> > impossible to know the threading model of the application that will be
> > using it.
> 
> Yes, adding a big fat warning sounds fair to me

Ok, I’ll work something together.

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

According to the docs, the only non-thread-safe call is 
QDBusConnection::sender, which is apparently kept for compatibility only since 
one should use QDBusContext in such cases instead.

Whether libdbus under it is thread safe (or used in a way that makes it thread 
safe), I don’t know. I’ll follow up with Thiago. It would be rather nice to 
see this class go away if possible.

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

That would be good information to have .. looking forward to their response.

-- 
Aaron J. Seigo