Somehow, attempts to bolt message passing onto Linux never seem to be very good. Probably because the primitives underneath are a poor match.<p>QNX, which is a real-time microkernel, got message passing more or less right. You connect to a port of another process. Then you send with MsgSend, which sends a message of N bytes, and waits for a reply. So it's like a procedure call.<p>The receiving end (considered the server) does MsgReceive, which blocks waiting for work, gets the bytes, and returns a reply with MsgReply. That's QNX messaging.<p>Everything goes through this, including all I/O. It's very fast, and integrated with the CPU scheduler, so most message passes just transfer control to the other end without scheduling delay. This allows rapid tossing of control back and forth between processes without going to the end of the line for CPU time.<p>Because QNX is a real-time OS, there are some additional features. Messages are ordered by thread priority, so real-time requests are serviced ahead of non-real time. (This works well enough that running a compile or a browser doesn't impact hard deadline real-time work.) Any request can have a timeout, in case the other end has a problem. Finally, when a MsgSend from a high priority process goes to a lower-priority process, the receiving process gets the higher priority until the MsgReply, to avoid priority inversion.<p>Linux messaging almost always goes through unidirectional byte pipes of some sort. So you need a protocol just to figure out where the message boundaries are. D-Bus seems to be struggling with that. Building a call-like mechanism on top of unidirectional pipes means that callers do a write followed by a read. For a moment, between the write and the read, both sender and receiver are ready to run. This means a trip through the scheduler, or worse, starting the receiving process on a different CPU and suffering cache misses.<p>It's one of those things where the wrong primitives at the bottom cascade into layers of complexity above.