News for hackers. Stuff that matters.
Re:Bus1 – Kernel Message Bus by tomegun on Thursday October 27, 2016 @07:36AM (#12804262)
Indeed that is how we break ties (not exactly the PID, but you get the idea).

The reason this works is that the only time we can have a tie is if there can be no causality between the events. I.e., the two sending events happen concurrently: the two ioctl calls overlap in time, so there would be no way for one to have caused the other.

What problem do you see with this?

Re:Bus1 – Kernel Message Bus by mfukar on Thursday October 27, 2016 @07:52AM (#12804322)
I foresee a problem where people confuse the wording of "total order on all messages" in the wiki to mean there is a "global total order" - in other words, that bus1 solves distributed systems and we can all go home - and building buggy systems on this assumption. I'm not saying the concept is flawed or the implementation buggy, or anything like that.

PS. Neil Brown in the LWN article already conflates "global" and "total" order.

Re:Bus1 – Kernel Message Bus by jasonwatkinspdx on Thursday October 27, 2016 @10:39AM (#12805416)
I'd suggest reading the hybrid logical clocks paper.
Re:Bus1 – Kernel Message Bus by mfukar on Thursday October 27, 2016 @11:11AM (#12805731)
I have - I'm actually working with it on a multi-version IPC provider (totally unrelated to bus1 & friends). Is it relevant here? I know they're the latest and greatest, but they're not without problems either.
Re:Bus1 – Kernel Message Bus by jasonwatkinspdx on Thursday October 27, 2016 @07:56PM (#12811581)
Based on your comments about lamport clocks, etc, I thought you'd find it interesting.
Re:Bus1 – Kernel Message Bus by mfukar on Friday October 28, 2016 @08:01AM (#12814941)
It is indeed. Cool applications too. I remember at least GUN - a graph db engine - uses them to great effect, and its author hangs out here, iirc.