4 ms·

D-Bus isn't suitable for realtime, to get that to work would require additional changes within the D-Bus daemon to add realtime scheduling, and even with all th

D-Bus isn't suitable for realtime, to get that to work would require additional changes within the D-Bus daemon to add realtime scheduling, and even with all that, it would still introduce latency because it requires an extra context switch from client -> dbus-daemon -> pipewire. Maybe they could have re-used the D-Bus wire format? That's the only bit that might have been suitable.

vlovich123 6y ago
To this day I still don't understand why messages are routed through dbus-daemon instead of just using FD-passing to establish the p2p connection directly. I remember we were using D-Bus on WebOS @ Palm & a coworker rewrote the DBus internals (keeping the same API) to do just that & the performance win was significant (at least 10 years ago).
- cycloptic 6y ago
  Among other things, pushing everything through the message bus allows for global message ordering, and security policies down to the individual message. Rewriting the internals would work in an embedded situation like that where every application is linking against the same version of libdbus, but that is not really the case on a desktop system, where there are multiple different D-Bus protocol implementations. If applications have hard performance requirements, most D-Bus implementations do have support for sending peer-to-peer messages, but applications have to set up and manage the socket themselves.
  - admax88q 6y ago
    Also lets you restart either end of the connection transparently to the other end. With fd passing, if the daemon I'm talking to dies or restarts my fd is now stale and i have to get another. Also allows starting things on demand similar to inetd. Also allows transparent multicast. So yeah, fd passing would be faster, but routing through the daemon is easier.
    - cycloptic 6y ago
      I didn't mention those because in theory a lot of that could be done by the library, or done by the daemon before passing off the fd for a peer-to-peer connection. (If a connection dies, the library would transparently handle that by sending a request back to the daemon for another connection, etc) But of course another thing that having a message bus allows you to do is reduce the amount of fds that a client has to poll on to just one for the bus socket.

vlovich123 6y ago

To this day I still don't understand why messages are routed through dbus-daemon instead of just using FD-passing to establish the p2p connection directly. I remember we were using D-Bus on WebOS @ Palm & a coworker rewrote the DBus internals (keeping the same API) to do just that & the performance win was significant (at least 10 years ago).

cycloptic 6y ago
Among other things, pushing everything through the message bus allows for global message ordering, and security policies down to the individual message. Rewriting the internals would work in an embedded situation like that where every application is linking against the same version of libdbus, but that is not really the case on a desktop system, where there are multiple different D-Bus protocol implementations. If applications have hard performance requirements, most D-Bus implementations do have support for sending peer-to-peer messages, but applications have to set up and manage the socket themselves.
- admax88q 6y ago
  Also lets you restart either end of the connection transparently to the other end. With fd passing, if the daemon I'm talking to dies or restarts my fd is now stale and i have to get another. Also allows starting things on demand similar to inetd. Also allows transparent multicast. So yeah, fd passing would be faster, but routing through the daemon is easier.
  - cycloptic 6y ago
    I didn't mention those because in theory a lot of that could be done by the library, or done by the daemon before passing off the fd for a peer-to-peer connection. (If a connection dies, the library would transparently handle that by sending a request back to the daemon for another connection, etc) But of course another thing that having a message bus allows you to do is reduce the amount of fds that a client has to poll on to just one for the bus socket.