Off-topic: D-Bus in the kernel

[Marcus Brinkmann]

On 09/21/2010 07:00 PM, Rémi Denis-Courmont wrote:
> Yes and no. I would agree that POSIX lacks a proper mechanism for multicasting 
> message (it seems using IP multicast on loopback is the only way). That's one 
> thing where DBus signals are really useful. Service 'name resolutoin' is also 
> nice to have.

Multicasting, IMO, raises serious resource management issues from a kernel
developers point of view (dunno if Linux people care about that, though).  You
won't find a modern microkernel supporting multicasting.  It's possible, but
very complicated to get right (where right means: no denial of service attacks
against the kernel or the servers, and full reliability, not just
probabilistic guarantees).

OTOH, service name resolution is of course part of POSIX, where it is called
"file system".  The problem here is that it is usually not user extensible
(something that is slowly being addressed with things like FUSE), see
http://www.walfield.org/papers/200707-walfield-critique-of-the-GNU-Hurd.pdf
(disclaimer: I am a co-author of that paper).

> But when it comes to request/response messages, it would be far more efficient 
> to establish a direct connection between the client and the server. This would 
> not only move most traffic out of the way of the DBus bus daemon, thus 
> increasing perfomance. It would also solve the head-of-line blocking problem 
> that is inherent to multiplexing multiple flows of informations over a single 
> stream (Unix socket).

The most direct connection you can get is shared memory, but even that
requires either lock free protocols or a synchronization primitive such as a
futex.

Thanks,
Marcus