<story><title>Rethinking the D-Bus Message Bus</title><url>https://dvdhrm.github.io/rethinking-the-dbus-message-bus/</url></story><parent_chain><item><author>Animats</author><text>&lt;i&gt;We rather consider a bus a set of distinct peers with no global state.&lt;/i&gt;&lt;p&gt;If they&amp;#x27;ve gone that far, they may as well implement QNX messaging, which is known to work well.  QNX has an entire POSIX implementation based on QNX&amp;#x27;s messaging system, so it&amp;#x27;s known to work. Plus it does hard real time.&lt;p&gt;The basic primitives work like a subroutine call.  There&amp;#x27;s MsgSend (send and wait for reply), MsgReceive (wait for a request), and MsgReply (reply to a request).  There&amp;#x27;s also MsgSendPulse (send a message, no reply, no wait) but it&amp;#x27;s seldom used. Messages are just arrays of bytes; the messaging system has no interest in content.  Receivers can tell the process ID of the sender, so they can do security checks.  All I&amp;#x2F;O is done through this mechanism; when you call &amp;quot;write()&amp;quot;, the library does a MsgSend.&lt;p&gt;Services can give their endpoint a pathname, so callers can find them.&lt;p&gt;The call&amp;#x2F;reply approach makes the hard cases work right. If the receiver isn&amp;#x27;t there or has exited, the sender gets an error return. There&amp;#x27;s a timeout mechanism for sending; in QNX, anything that blocks can have a timeout. If a sender exits while waiting for a reply, that doesn&amp;#x27;t hurt the receiver. So the &amp;quot;cancellation&amp;quot; problem is solved.  If you wan to do something else in a process while waiting for a reply, you can use more threads in the sender. On the receive side, you can have multiple threads taking requests via MsgReceive, handling the requests, and replying via MsgReply, so the system scales.&lt;p&gt;CPU scheduling is integrated with messaging. On a MsgSend, CPU control is usually transferred from sender to receiver immediately, without a pass through the scheduler. The sending thread blocks and the receiving thread unblocks.&lt;p&gt;With unidirectional messaging (Mach, etc.) and async systems, it&amp;#x27;s usually necessary to build some protocol on top of messaging to handle errors. It&amp;#x27;s easy to get stall situations. (&amp;quot;He didn&amp;#x27;t call back! He said he&amp;#x27;d call back! He promised he&amp;#x27;d call back!&amp;quot;) There&amp;#x27;s also a scheduling problem - A sends to B but doesn&amp;#x27;t block, B unblocks, A waits on a pipe&amp;#x2F;queue for B and blocks, B sends to A and doesn&amp;#x27;t block, A unblocks. This usually results in several trips through the scheduler and bad scheduling behavior when there&amp;#x27;s heavy traffic.&lt;p&gt;There&amp;#x27;s years (decades, even) of success behind QNX messaging, yet people keep re-inventing the wheel and coming up with inferior designs.</text></item></parent_chain><comment><author>tomegun</author><text>Please note that this is still an implementation of the D-Bus specification, but trying to adhere to the principle of distinct peers. As is explained, this is not entirely possible when implementing D-Bus, so it is nothing more than a guiding principle.</text></comment>
<story><title>Rethinking the D-Bus Message Bus</title><url>https://dvdhrm.github.io/rethinking-the-dbus-message-bus/</url></story><parent_chain><item><author>Animats</author><text>&lt;i&gt;We rather consider a bus a set of distinct peers with no global state.&lt;/i&gt;&lt;p&gt;If they&amp;#x27;ve gone that far, they may as well implement QNX messaging, which is known to work well.  QNX has an entire POSIX implementation based on QNX&amp;#x27;s messaging system, so it&amp;#x27;s known to work. Plus it does hard real time.&lt;p&gt;The basic primitives work like a subroutine call.  There&amp;#x27;s MsgSend (send and wait for reply), MsgReceive (wait for a request), and MsgReply (reply to a request).  There&amp;#x27;s also MsgSendPulse (send a message, no reply, no wait) but it&amp;#x27;s seldom used. Messages are just arrays of bytes; the messaging system has no interest in content.  Receivers can tell the process ID of the sender, so they can do security checks.  All I&amp;#x2F;O is done through this mechanism; when you call &amp;quot;write()&amp;quot;, the library does a MsgSend.&lt;p&gt;Services can give their endpoint a pathname, so callers can find them.&lt;p&gt;The call&amp;#x2F;reply approach makes the hard cases work right. If the receiver isn&amp;#x27;t there or has exited, the sender gets an error return. There&amp;#x27;s a timeout mechanism for sending; in QNX, anything that blocks can have a timeout. If a sender exits while waiting for a reply, that doesn&amp;#x27;t hurt the receiver. So the &amp;quot;cancellation&amp;quot; problem is solved.  If you wan to do something else in a process while waiting for a reply, you can use more threads in the sender. On the receive side, you can have multiple threads taking requests via MsgReceive, handling the requests, and replying via MsgReply, so the system scales.&lt;p&gt;CPU scheduling is integrated with messaging. On a MsgSend, CPU control is usually transferred from sender to receiver immediately, without a pass through the scheduler. The sending thread blocks and the receiving thread unblocks.&lt;p&gt;With unidirectional messaging (Mach, etc.) and async systems, it&amp;#x27;s usually necessary to build some protocol on top of messaging to handle errors. It&amp;#x27;s easy to get stall situations. (&amp;quot;He didn&amp;#x27;t call back! He said he&amp;#x27;d call back! He promised he&amp;#x27;d call back!&amp;quot;) There&amp;#x27;s also a scheduling problem - A sends to B but doesn&amp;#x27;t block, B unblocks, A waits on a pipe&amp;#x2F;queue for B and blocks, B sends to A and doesn&amp;#x27;t block, A unblocks. This usually results in several trips through the scheduler and bad scheduling behavior when there&amp;#x27;s heavy traffic.&lt;p&gt;There&amp;#x27;s years (decades, even) of success behind QNX messaging, yet people keep re-inventing the wheel and coming up with inferior designs.</text></item></parent_chain><comment><author>AceJohnny2</author><text>So, SIMPL?&lt;p&gt;&lt;i&gt;Synchronous Interprocess Messaging Project for LINUX (SIMPL) is a free and open-source project that allows QNX-style synchronous message passing by adding a Linux library using user space techniques like shared memory and Unix pipes[3] to implement SendMssg&amp;#x2F;ReceiveMssg&amp;#x2F;ReplyMssg inter-process messaging mechanisms.&lt;/i&gt;&lt;p&gt;&lt;a href=&quot;https:&amp;#x2F;&amp;#x2F;en.wikipedia.org&amp;#x2F;wiki&amp;#x2F;SIMPL&quot; rel=&quot;nofollow&quot;&gt;https:&amp;#x2F;&amp;#x2F;en.wikipedia.org&amp;#x2F;wiki&amp;#x2F;SIMPL&lt;/a&gt;&lt;p&gt;&lt;a href=&quot;http:&amp;#x2F;&amp;#x2F;icanprogram.com&amp;#x2F;simpl&amp;#x2F;&quot; rel=&quot;nofollow&quot;&gt;http:&amp;#x2F;&amp;#x2F;icanprogram.com&amp;#x2F;simpl&amp;#x2F;&lt;/a&gt;</text></comment>