D-Bus optimizations

[Thiago Macieira]

On quarta-feira, 14 de março de 2012 12.08.33, Colin Walters wrote:
> 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?

Or, asked differently: who would consciously opt out? Or another question: what 
are the use-cases for total ordering?

Here's just a wild idea not completely thought through: use the ordering 
semantics found in memory and in the C++11 and C11 standards. 

Each message send and each message receive indicate its level of ordering, 
which can be:

 - relaxed: no ordering applied relative to other messages
 - acquire / release: if message M1 is sent before M2 and M2 is sent as 
"release", and M2 is received with "acquire", then M1 must have been delivered 
already; if "relaxed" message M3 is sent after M2, it *may* be delivered 
before M2.
 - sequentially consistent: same as acquire/release, but applies to all 
connections

The difference between the latter two appear when there are three processes 
communicating.

Now, I have little idea on how to implement this concretely. It would only 
make sense if the many connections all had random-access to the messages being 
sent, such as in a shared memory scenario. Doing that with a sequential 
channel would require having large buffers to keep the messages received out of 
order when an order is required.

-- 
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
   Software Architect - Intel Open Source Technology Center
      PGP/GPG: 0x6EF45358; fingerprint:
      E067 918B B660 DBD1 105C  966C 33F5 F005 6EF4 5358
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 190 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.freedesktop.org/archives/dbus/attachments/20120314/d5f2a70c/attachment.pgp>