kdbus, bus1 and systemd/non-linux hosts

[René J.V. Bertin]

On Tuesday April 11 2023 08:44:34 Lawrence D'Oliveiro wrote:

>I thought you were asking for “similar alternatives” to D-Bus.

Sorry, I suppose I meant similar alternatives to KDBus or Bus1 *with a compatibility layer allowing them to be used as drop-in replacements for D-Bus.

----------------------------------------------------------------
On Tuesday April 11 2023 10:21:18 Thomas Kluyver wrote:

>This seems like a confusing request, at least to me. You start off talking about mechanisms that were meant to be part of the Linux kernel, but then you ask for cross-platform solutions. A messaging system built on sockets, like D-Bus, can be cross-platform much more easily than something built on a Linux-specific kernel feature.

I can see how it can seem confusing, but maybe it's a bit less so when you take into account that KDBus and Bus1 were at least in part inspired by comparable features provided by the Mac & MSWin kernels.

>And D-Bus does work on Mac and Windows

I know, I probably used it on Mac first.

> It sounds like people found it was possible to write a higher-performance D-Bus message bus even without new kernel features, and this is where dbus-broker comes from.

By enlisting the help of another daemon? :)

>Have you actually figured out that D-Bus itself is causing the slowness, and not whatever KMail is talking D-Bus to? Or is that a guess? It's *really* hard to guess correctly about performance in complex systems, so chasing ways to make D-Bus faster might well be a waste of time.

I know, and yes, it's mostly a guess. I did however see mention of similar "nothing happens without any clear CPU burning" episodes in reports of comparing performance of the standard D-Bus with that using a kernel conduit.

FWIW, KMail uses "akonadi daemons" for the actual mail fetching, and talks with them over the D-Bus. I have already confirmed that the sluggishness I observe from time to time doesn't (systematically) exist in more traditional IMAP MUAs, i.e. that it's not by definition a network or remote server issue.

>Your old/cheap systems probably wouldn't see much, if any, benefit from a multithreaded dbus-daemon. Though that's a guess too. ;-)

That's quite possible too, at least not if clients cannot specify the priority of their requests and are being honest about it... BTW, I suppose we'd probably be talking about a model where each thread corresponds to a client connection and not one where individual requests are handled in parallel on individual threads (which would probably just introduce overhead due to the requirement on maintaining the chronological order).