"DBus Embedded" - a clean break

Philip Van Hoof spam at pvanhoof.be
Wed Jan 26 07:11:07 PST 2011


On Wed, 2011-01-26 at 09:58 -0500, David Zeuthen wrote:

Hi David,

> On Wed, Jan 26, 2011 at 9:20 AM, Philip Van Hoof <spam at pvanhoof.be> wrote:
> > Unfortunately is a shiny new D-Bus library making a similar mistake with
> > its g_dbus_message_to_blob in write_message_continue_writing and
> > maybe_write_next_message stuff in its gdbusprivate.c.
> 
> No, Philip, it's not a mistake that GDBus is written in this way so
> please don't call it a mistake.

So a patch that avoids the use of g_dbus_message_to_blob would
definitely not be accepted, because GDBus is 'written this way'? :-)

I didn't say it's not written this way. Obviously it is. No argument
there.

What I mean is that GDBus can probably be improved in performance if it
wouldn't do the g_dbus_message_to_blob but would instead write chunks to
the socket while iterating over the message.

> I'll repeat what I've said earlier: if you want low latency / high
> bandwidth, the D-Bus protocol greatly limits what you can do (instead,
> mmap binary data between processes, use raw sockets etc. - look at
> dconf/GVfs for inspiration). Additionally, D-Bus / message buses can
> still be a great help in orchestrating custom IPC given the number of
> guarantees (name ownership, validation etc.) it gives you.

> Think about it. Why would you put constraints on your app in the name
> of "we need to use the same IPC everywhere"? Instead, optimize the hot
> spots of your IPC by moving parts of it away from D-Bus to e.g.
> mmap(2) or a socket or whatever. Just like you'd optimize the inner
> loop of a 3D engine by writing the scan converter in assembly instead
> of C (my 3D skills are mid-90 pre-shader vintage so go easy on the
> analogy).

David, relax.

In my E-mail I concluded at the end that D-Bus FD-passing should today
be used by applications that pass significant amounts of data. This
supports your view on this.

Nonetheless are there things that can be improved in both libdbus and
GDBus, and should be.

At Tracker we saw a performance drop of a few percentages after we moved
from libdbus to GDBus (and yes, we already use FD passing). You're not
convincing me than doing worse than libdbus is a good design goal.

> This notion that we absolutely need to fit square pegs in round holes
> need to stop.

I don't understand this analogy.

Cheers,

Philip



-- 


Philip Van Hoof
freelance software developer
Codeminded BVBA - http://codeminded.be



More information about the dbus mailing list