"DBus Embedded" - a clean break

Lennart Poettering mzqohf at 0pointer.de
Thu Feb 3 13:22:42 PST 2011


On Wed, 26.01.11 15:20, Philip Van Hoof (spam at pvanhoof.be) wrote:

> 
> On Thu, 2011-01-20 at 09:53 +0200, Ville M. Vainio wrote:
> 
> Hi Ville M. Vainio,
> 
> > Just some subversive thoughts (not a practical development project for now):
> > 
> > - Dbus is very slow. It's okay on desktop, but on mobile platforms
> > it's suboptimal
> > 
> > - It could be much (10x?) faster - switch to shared memory, posix
> > message queues for data transmission (references to relevant shared
> > memory blocks), do not do any verification
> 
> This implies changing libraries like GDBus, which doesn't use libdbus,
> too. I'm also not sure how portable shm and posix message queues are.

POSIX MQs are kinda useless for most purposes. AF_UNIX sockets with
SOCK_SEQPACKET are much more useful in the general case. And using POSIX
MQ descriptors as fd's in poll() is not portable, which makes it really
hard to integrate them into anything. The suggested way to do async MQ
stuff is via signals and that's just fucked up. Superduper fucked up.

I really wonder why anybody would want to use POSIX MQs, except if they
want to make use of the priority stuff, which however is not useful in
the D-Bus context. Just because something is new doesn't mean it's
actually useful in real-life.

And as I wrote elsewhere SHM is hardly useful if you need to care about
perms, which we do for the system bus.

Before people suggest using SHM or POSIX MQs in D-Bus they should do
first there homework and show that a) the resulting code is manageable
and safe and b) there's actually really an improvement.

Lennart

-- 
Lennart Poettering - Red Hat, Inc.


More information about the dbus mailing list