"DBus Embedded" - a clean break

[Philip Van Hoof]

On Thu, 2011-01-27 at 09:59 +0000, Michael Meeks wrote:

Hi Michael!

> On Wed, 2011-01-26 at 09:58 -0500, David Zeuthen wrote:
> > 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
> 
> 	This is clearly both true, and not that helpful :-) People don't need
> something 10,000 times faster, only ~ten - and that is quite achievable
> by optimising GDBus IMHO :-)

Not only do people want something that is ~ 10 times faster (which is
also a lot, tbh). In embedded and mobile they also want something that
doesn't arbitrarily wake up other processes.

For example: when dbus-daemon isn't necessarily involved in an IPC
exchange between two entangled processes, then ideally the IPC system
doesn't needlessly wake it up.

And ideally that also holds for signals (ie. use a broadcast mechanism,
but then I don't immediately know how the arg0 filtering would work).

Maybe something like this? Getting the kernel involved isn't a nice
solution either imho:

http://alban.apinc.org/blog/2010/09/15/d-bus-in-the-kernel-faster/

A reason why you don't always want to let IPC depend on arbitrary
processes is scheduling prioritization. Having to wait on a SCHED_RR in
a SCHED_FIFO, etc. That yield ain't always going to be so nice, and
during development it's sometimes a surprise / unexpected.

The power-management people also enjoy giving us powertop logs with
dbus-daemon hiding that a D-Bus abusing process is causing significant
battery drain ..

People generally don't like it when their tablets and phones last only a
few hours on battery. Admittedly it's not dbus-daemon itself.

> Also, there is a very very substantial cost in maintainability,
> readability, debugability and so on cooking up custom IPC protocols
> left and right. Surely this is why we try to standardise a single
> IPC mechanism, rather than having every different app use a
> different mechanism.

Full agreement.

> 	It is somewhat ironic to me (amid all the talk of the joys of cooking
> custom protocols), that one of the complicating factors to GDBus's
> performance is allowing protocol re-use via telepathy tubes :-) Surely
> that is an ideal area to "just create another protocol" if there is any.
> 
> > 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
> 
> 	So - IMHO cooking your own IPC is more analagous to writing your own
> language, than switching language choice; and again it is assumed that
> there is a need for something 1000x faster, when in many cases there is
> not.

Agree

> > This notion that we absolutely need to fit square pegs in round holes
> > need to stop.
> 
> 	The notion that it is trivial to constantly re-invent IPC mechanisms,
> one per task, and that the extra bloat, bugs, reliability, and
> discoverability problems etc. are worth having needs killing dead on
> sight IMHO :-)
> 
> 	It is clearly the case, that standardisation helps - a lot; to twist
> your analogy: using a different thread on each screw, and making each
> nut and bolt fit only each other is not a recipie for good
> engineering :-)

Agree

> 	But of course, since I'm not working on optimising the code, I'll shut
> up now ;-)

Cheers,

Philip

-- 


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