[prev in list] [next in list] [prev in thread] [next in thread] 

List:       freedesktop-dbus
Subject:    Re: kdbus, bus1 and systemd/non-linux hosts
From:       René_J.V. Bertin <rjvbertin () gmail ! com>
Date:       2023-04-11 11:28:04
Message-ID: 3044027.ooNgSjo1ft () bola
[Download RAW message or body]

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).


[prev in list] [next in list] [prev in thread] [next in thread]