D-Bus Spec: "D-Bus is a system for low-latency, low-overhead, easy to use IPC"? (Re: D-Bus optimizations)

[Justin Lee]

Hi list,

I'm new to here ...

On Thu, Mar 8, 2012, Havoc Pennington <hp at pobox.com> wrote:
> In some places the docs are just screwy. For example
> the spec has the "low latency" bullet point but the
> description of the bullet is that dbus is supposed to
> make it easy to be _async_, which is not the same as
> low latency at all.

The original text in the spec.
http://dbus.freedesktop.org/doc/dbus-specification.html#introduction
is:
D-Bus is a system for low-latency, low-overhead, easy to use
interprocess communication (IPC). In more detail:
* D-Bus is low-latency because it is designed to avoid round trips and
allow asynchronous operation, much like the X protocol.

If I don't get it wrong, latency is unrelated to whether the operation
is asynchronous or synchronous. It should be also unrelated to whether
it's one-way or round-trip. According to Wikipedia
http://en.wikipedia.org/wiki/Latency_%28engineering%29#Packet-switched_networks
latency means "the time from the source sending a packet to the
destination receiving it". So latency exists for asynchronous and
one-way transfer, because for current DBus implementations we need at
least one context switch to transfer each message from the sender
process to the receiver process. The wording in spec is kind of
obscure. I suggest we should delete the second line and the
"low-latency" in the first line.

On Thu, Mar 8, 2012, Mikkel Kamstrup Erlandsen
<mikkel.kamstrup at canonical.com> wrote:
> I am seeing time and time again people mapping OO designs to bus objects and
> it can only lead to performance problems. They are doing this because this
> is what all online examples tell them to do. One must think in batched
> calls, stateless requests, and idempotency to devise fast and robust
> protocols.

On Thu, Mar 8, 2012, Havoc Pennington <hp at pobox.com> wrote:
> I think you're right that the docs probably don't hammer on this point
> enough and don't go into enough detail on when to use a shared library
> vs. IPC, and how dbus APIs should be designed for things to be sane.

Well, I have no idea what are the preconditions to modify our official
docs and who has the privilege to modify them.

But I notice there are lots of explanation in this mailing list and
there are many links to external sites/blogs, all of which are talking
about how to optimize code for DBus. So how about fix our official
docs first directly? After all, DBus docs should be the major
reference for every user rather than mails and blogs IMO. The docs
should be clear to avoid misusage.

Justin