libdbus or gio dbus for multi-threaded service ?

[Simon McVittie]

On Wed, 14 Mar 2018 at 12:57:03 +1300, Lawrence D'Oliveiro wrote:
> On Tue, 13 Mar 2018 12:40:10 +0000, Simon McVittie wrote:
> 
> > ... and in particular [libdbus] does not have any way to
> > schedule callbacks to be called in the context (thread) where the
> > user that set up that callback might expect it to be called.
> 
> Is that all it is?

No, there is also a general worry that libdbus is probably less
thread-safe than it was always meant to be, because we don't have a
systematic model for what runs where, etc., which makes it very hard to
say whether everything we do follows the intended model.

(Of course making a systematic model is a lot harder when we can't know
which thread our callbacks are going to be called in.)

For context, libdbus was already meant to be thread-safe in 2003, and
we fixed a threading bug in DBusPendingCall (#102839) as recently as
January. That bug seems to have been present and undiagnosed for about
15 years, so I think I can quite confidently say that there are probably
more threading bugs.

> I remember a little while back when I mentioned that
> I was introducing limited multithreading into DBussy, my Python wrapper
> for libdbus <https://github.com/ldo/dbussy> to give the effect of
> nonblocking calls, and received some rather scary comments in reponse.
> But when I asked for clarification, none was forthcoming.

If we knew precisely how multi-threading wasn't reliable, we'd be a step
closer to fixing it. At the time of making those scary comments, I don't
think we knew the specifics of #102839 yet.

> For what it’s worth, DBussy handles all libdbus callbacks on the same
> thread ... so long as the caller doesn’t invoke it on additional
> threads.

I would recommend documenting what use patterns are and aren't supported
for multi-threaded users of DBussy, if you haven't already (if in doubt,
be conservative, by not saying you support things that you aren't sure
about). One possibility is "each object can only be used from the thread
that created it", which is how systemd's sd-bus API works, and is also
a conservative approach to interacting with libdbus.

    smcv