Starting the kdbus discussions

[Lennart Poettering]

On Fri, 17.01.14 13:59, Thiago Macieira (thiago at kde.org) wrote:

> On sexta-feira, 17 de janeiro de 2014 19:42:55, Simon McVittie wrote:
> > This turns out to lead to a confusing architectural train-wreck, and
> > still doesn't get callbacks called in the right main-context - they all
> > turn up in whatever main context is "dispatching", and if you want them
> > to go elsewhere you have to post events between threads.
> > 
> > I'm not sure how QtDBus (which wraps libdbus) deals with this: I think
> > it might do it by asserting the policy "async callbacks always go off in
> > the Qt main thread, which is where I dispatch the connection; you must
> > run the Qt main-loop in your main thread", and in practice that's how
> > people use Qt anyway, so it works out OK?
> 
> That's exactly it. But worse.
> 
> The thread that first created the connection becomes responsible for always 
> handling the socket. So there's a big problem if some user thread gets started 
> and accesses D-Bus, but never runs an event loop or if it exits. Then that D-
> Bus connection will never receive incoming calls or signals because there's 
> nothing to handle its socket.
> 
> The other problem that David described also exists: if one thread does a 
> blocking call, then all threads must wait.
> 
> One of the things I really want to do for QtDBus when we start working on 
> kdbus support is to add a worker thread. Our plans[1] say that:

I'd really suggest you not do that. Yesterday, kdbus learned support for
doing synchronous method calls in a single client-side ioctl. This opens
the door for passing the CPU directly to the destination service, and
back, possibly inheriting scheduling priority. This design brings us
really close to the performance behaviour of micro kernel operating
systems or the android binder. If you make everything indirect by a
worker thread you will lose that and this cannot be worked around.

I'd recommend to either not share bus connections across threads (which
is the approach we followed for libsystemd-bus), or to make sure that
the bus object's locks are released while a thread poll()s on it.

Note that kdbus connections are considerably cheaper and quicker to
set up than dbus1 connections: there's no complex duplex setup protocol,
there's just an open() on a device node, and one ioctl. Hence sharing
bus connections between threads is much less beneficial than it was on
dbus1. (Of course you might still share the message cache and so on, but
that's independent of this question...)


Lennart

-- 
Lennart Poettering, Red Hat