Re:Bus1: a new Linux interprocess communication proposal
by tomegun on Tuesday August 23, 2016 @11:15AM
(#12344367)
I don't see how. We should handle side-channel communication just fine. Care to give an example?
[ Parent
| on HN ]
Re:Bus1: a new Linux interprocess communication proposal
by gpderetta on Friday August 26, 2016 @10:26AM
(#12366486)
proc1 sends a message to proc2 via bus1, then sends a signal to proc3 via a shared memory channel by incrementing a counter in shared memory; proc3 sees the message and signals proc4 via bus2;
There is no partial ordering between proc1->proc2 and proc3->proc4 as the memory channels are invisible to bus1, but Proc2 and proc4 can detect the total ordering violation by using another counter in shared memory.
Re:Bus1: a new Linux interprocess communication proposal
by tomegun on Monday August 29, 2016 @10:40AM
(#12382123)
Right, we only enforce the _order_ of message delivery, not the _time_ of deliver. I.e., consider the sequence of messages received on each peer, these sequences each respect a global, total order on all messages. But there are no timestamps on them, and no way to compare sequences from separate peers.