Off-topic: D-Bus in the kernel

[Havoc Pennington]

Hi,

2010/9/21 Rémi Denis-Courmont <remi at remlab.net>:
> So you're saying Telepathy should not use DBus the way it does, I guess.
>

I don't really know how Telepathy works. Just based on watching list
traffic, I have the impression it may use dbus in some cases when I
would personally have used a dlopen() module or something. But, again,
I don't really know.

> Sure. But it seemed to me that libdbus did not really make peer-to-peer DBus
> so easy (though it certainly allows it).

It isn't super easy, though I don't think it's super hard either.
Mostly not much attention here because for the most part nobody has
seemed to need it (or not needed it enough to start patching and/or
suggesting APIs, anyhow)

The one thing that happened in this area was Lennart adding the
fd-passing support, which is one way to set up a peer-to-peer link (in
that case, not one that then speaks dbus though).

> I guess I did not mean to say DBus is misdesigned, but misused then. Most
> applications use DBus correctly as a rendez-vous mechanism, but also
> incorrectly for peer-to-peer signaling.

It's fine for messages generally. It just isn't good if you're going
to shovel some giant boatload of data or have realtime constraints or
something.

the idea of dbus is if you want to send messages like "open this
document" or "suspend screensaver" or do startup-notification protocol
 or NetworkManager or things like that. These are the 90% case for the
session and system bus. Maybe 95% or more. The other cases just aren't
solved by dbus. But they weren't solved before that, either.

> If two clients A & B try to send a message to the same client C, one (say B)
> will have to wait for the other (say A).  Then if B also wants to send a
> message to a forth client D, the message to D will be stuck in B's queue.
> Effectively, the communication between B & D ends up being blocked by the
> communication between A & C.
>
> You can mitigate it with low message size limits and/or large receive buffers
> on the bus daemon to *some* extent.

dbus-daemon will buffer any message that's permitted, I think. (i.e.
as long as you're under the size limit that's allowed at all, then
it'll buffer; otherwise it will throw an error up front). If it
doesn't have RAM to buffer it should throw an error. So none of the
clients would actually block. B could send to D even though C has not
read from B yet. Where things would block is if B decided to block for
C to reply. It's up to B whether to do this.

Havoc