News for hackers. Stuff that matters.
Re:Bus1: a new Linux interprocess communication proposal by Pyxl101 on Thursday August 18, 2016 @12:49AM (#12310476)
The design goals of bus1 are described here: https://lists.linuxfoundation.org/pipermail/ksummit-discuss/...

Some call-outs for you:

> * efficiently support n-to-n communication. * be well-suited for both unicast and multicast messages. * guarantee a global message order. * avoid any in-kernel buffering and rather transfer data directly from a sender into the receiver's mappable queue (single-copy).

The downside of the alternatives that you mention is that they're not available as kernel features in Linux. Bus1 is inspired by that previous work and aims to make a new attempt at inclusion in the kernel, which they believe is required to provide the features they're targeting:

> A user-space implementation of bus1 (or even any bus-based IPC) was considered, but was found to have several seemingly unavoidable issues.

> o To guarantee reliable, global message ordering including multicasts, as well as to provide reliable capabilities, a bus-broker is required. In other words, the current linux syscall API is not sufficient to implement the design as described above in an efficient way without a dedicated, trusted, privileged process that manages the bus and routes messages between the peers. (...)

Re:Bus1: a new Linux interprocess communication proposal by pjc50 on Thursday August 18, 2016 @02:12AM (#12310691)
Global message order sounds like the kind of commitment that becomes increasingly expensive in a multi core environment..
Re:Bus1: a new Linux interprocess communication proposal by grandinj on Thursday August 18, 2016 @03:56AM (#12310994)
hence the use of some nifty optimised clocking algorithms:

https://github.com/bus1/bus1/wiki/Message-ordering

Re:Bus1: a new Linux interprocess communication proposal by tomegun on Thursday August 18, 2016 @09:14PM (#12317388)
The overhead due to the message ordering is constant, irrespective of the number of cores/peers. See the link posted above for an explanation.