dbus & preempt-rt compatibility patch

[Simon McVittie]

On 07/03/14 15:06, VITIELLO Fabien wrote:
> In my project, Dbus will transfer messages with high priority for RT
> needs and others with normal priority for basic operations.

I don't think dbus-daemon is likely to be suitable for hard real-time.
kdbus might possibly be suitable for RT when it's finished, although I
doubt it (D-Bus probably imposes too many guarantees for it to be able
to have RT behaviour). In any case, kdbus isn't finished yet.

Fundamentally, dbus-daemon is based on a "star topology" of Unix or TCP
sockets. Reading messages out-of-order based on priority is not
feasible, and would break the API guarantees that D-Bus gives[1]. The
most it can do in terms of prioritization is to alter the order in which
it reads from the set of ready sockets after poll() returns, and that
isn't currently implemented either.

dbus-daemon also isn't preemptible: as soon as it has received the last
byte of a message and decided to dispatch it to listening processes, it
will not process any other messages until it has finished with that one.

There might be some scope for using two instances of dbus-daemon, one
running with high priority and one running with low priority, and
dealing with the fact that message ordering between those is not at all
guaranteed... but if you need RT then I suspect that D-Bus is not the
right IPC mechanism for your project.

    S

----

[1] Standard D-Bus usage (as seen in dbus-daemon) imposes a total
ordering on messages. The conceptual model is that every process sees
all messages on a given bus in the same order.

Specifically, suppose process A sends messages (A1, A2) on the same bus
in that order, and process B sends messages (B1, B2) on the same bus in
that order at approximately the same time. If processes C and D are
listening for all those messages:

* C receives A1 before A2
* C receives B1 before B2
* other than that, the order in which C receives messages is undefined
  (for instance they might go (A1, B1, A2, B2) or (A1, A2, B1, B2) or
  (A1, B1, B2, A2))
* D receives messages in the same order as C, whatever that is

If you have more than one bus, all bets are off - the relative order
between buses is completely undefined. Similarly, if process A has two
connections to the same bus, they behave like independent processes for
ordering purposes.