Starting the kdbus discussions

[Thiago Macieira]

On segunda-feira, 20 de janeiro de 2014 12:35:21, Lennart Poettering wrote:
> > 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.

Given what I've read and seen of kdbus so far, it looks like the best way 
would be for blocking sync calls to be placed from the thread that made the 
high-level call itself, instead of adding to a queue and waiting on the worker 
thread.

For regular Unix sockets, which we must still support, the worker thread 
provides a simpler solution. I will keep your suggestion in mind when 
designing the code. It shouldn't be too difficult (hopefully).

However, there's simply no way of doing that for incoming calls. With a 
connection shared between threads, there's no way of knowing ahead of time 
which thread will be processing the message. In simple implementations (I'm 
thinking of Java), a thread could even be started to process the message. So 
the incoming timeslice would either need to be given to the entire process, or 
instead there should be a way for one thread in a thread group to pass its 
priority to another.

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

Option 1 is just not possible. That boat sailed 7 years ago, when a huge 
codebase started sharing connections among threads.

Option 2 is just common sense, though it might only occur to you in hindsight. 
:-)

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

What they don't share are the known service names. And even if they did, the 
caller would not know which thread the call should go to.

-- 
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
   Software Architect - Intel Open Source Technology Center
      PGP/GPG: 0x6EF45358; fingerprint:
      E067 918B B660 DBD1 105C  966C 33F5 F005 6EF4 5358
-------------- 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://lists.freedesktop.org/archives/dbus/attachments/20140120/480688e8/attachment-0001.pgp>