Two instances of D-BUS in realtime context

[Simon McVittie]

On 18/03/14 14:12, Zzz Rrr wrote:
>     I have to use an IPC in a realtime context for a project

If when you say real-time you really mean "guaranteed response within a
deadline", D-Bus is highly unlikely to be the right thing. See the
recent thread "Subject: dbus & preempt-rt compatibility patch" on this
mailing list.

> If I uses DBUs, do you know if I
> can have two different bus with different priority level ?

You can have two dbus-daemon processes and give them different OS-level
process priorities. However, dbus-daemon still doesn't offer any timing
guarantees, and many of the nice high-level properties of D-Bus, like
total order on messages and (relatively) simple high-level APIs, will
not be present if you do that.

Fundamentally, current D-Bus consists of sending messages in a
bytestream (usually a Unix SOCK_STREAM socket, or occasionally TCP),
with byte-counting-based framing. Conventionally, it's done in a "star"
topology with the dbus-daemon in the middle, although it can also be
done in a peer-to-peer way (analogous to one process listening on a TCP
socket and the other connecting to it) if you don't mind discarding some
of the benefits of the high-level API. There's nothing magic about it:
if you can't think how you'd provide a particular performance feature in
that framework, then D-Bus probably doesn't have that performance feature.

D-Bus is most appropriate for OS- or session-level "signalling" with
low-frequency, medium-sized messages (a small number of messages per
user action or "interesting event", usually in the bytes or kilobytes
range). For instance, in the Telepathy real-time communications
framework, we use D-Bus to signal things like "new incoming file
transfer" or "call ended because there was no answer", but the actual
audio/video data for VoIP calls, and the actual file in a file transfer,
deliberately do not go over D-Bus.

    S