Starting the kdbus discussions

[Simon McVittie]

On 17/01/14 20:06, Lennart Poettering wrote:
> A thread which wants to do a synchronous message call would simply take
> the lock, write the message or as much as it can of that, then unlock,
> and poll() on the socket, and when it is writable/resable again, write
> the rest, of course only after retaking the lock. It does this as long
> as the message is not fully written or the reply not fully received. As
> many threads as you like can do this in parallel. This would mean that
> a message one thread incompletely writes could be finished by another
> thread and so on. But that's totally OK.

In kdbus, maybe that's OK, but in the D-Bus-over-SOCK_STREAM currently
described in the D-Bus Specification, it certainly isn't. Once you have
started writing a message into the Unix or TCP stream, you must finish
that message before starting the next. There is no framing/packetization
beyond "each message has a byte-count near the beginning".

> Note that with libsystemd-bus we explicitly are not thread-safe, though
> threads-aware. In contrast to gdbus and libdbus1 we don't want to play
> locking games, so what shifted the focus from
> one-shared-connection-per-process to
> one-shared-connection-per-thread. We believe this suits the global
> ordering model of dbus better, and makes our code a lot simpler.

I'm sure it makes your code a lot simpler, and I often wish libdbus
could do the same.

However, please note that the global ordering model does not guarantee
anything about ordering between connections that happen to share a
process. When there was a bug in the well-known (session, starter,
system) connection sharing in single-threaded dbus-glib, we saw it as
real (and hard-to-diagnose!) bugs in Telepathy - message orderings that
"clearly can't happen", resulting in, for instance, more than one
call-UI window appearing for the same VoIP call. That doesn't directly
apply to "one connection per thread", because that environment doesn't
have ordering guarantees without external synchronization anyway, but
encouraging multiple connections to the same well-known bus is still
something I'm wary of.

I'm not saying that libsystemd-bus doesn't have a valid choice of
trade-offs, but it is not a choice that is compatible with GDBus' and
libdbus' existing API guarantees. You've chosen one of the possible
routes, GDBus chose another.

    S