walters at verbum.org
Wed Mar 14 09:08:33 PDT 2012
On Wed, 2012-03-14 at 10:03 +0100, Bart Cerneels wrote:
> Context switches is the biggest single problem to be solved since it
> causes priority inversions. The anecdotal case was just to point out
> the underlying architectural problem causes very real bugs. Don't think
> it's the only project stumbling on this, just the best understood.
> Here is some supporting material:
> Notice the heavy emphasis on priority and scheduling.
Pretty good document - thanks! A few random comments, no particular
*) PLT overhead: We could apply -Bsymbolic-functions (like GLib does)
for the daemon and library pretty easily.
*) Skeptical of the "break DBus up into independent features" idea...
that sounds like it'd create a compatibility Matrix From Hell. What
would you do if one client desired total ordering but the other
didn't care, etc?
So skipping down to the end where you propose a "hybrid" approach
starting with the "D-Bus Proxies". I'm uncertain how it solves the
priority inversion problem unless we also dispense with total ordering.
If for example upower wants to send a "battery low" signal, the signal
gets queued out to the proxy, which then determines the recipients, but
in the current semantics if some other process runs at a different
priority level, the proxy still needs to block in order to write the
Also with D-Bus Proxies we'd be taking a step backwards on context
switching initially =( This then gets to the claim that shared memory
will fix that, but after all of this work it seems to me that we're
almost just back to where we started almost - we could just do the
equivalent thing by multi-threading dbus-daemon, no?
What I keep coming back to is basically that we could make things
noticeably better if we dropped the total ordering guarantee. I'm not
sure at all how to do that sanely though - it could be a negotiated
"feature" but would people really opt in?
More information about the dbus