- GenodeOS is reportedly used in production by some commercial clients, though mostly undisclosed IIRC; it is a higher-level layer (~OS) compatible with numerous microkernels
- Fuchsia OS - in dev; it's a recent development by Google; as much as Google is officially silent about it (I understand they're not sure how the experiment will work out for them), observers assume it's most probably hoped to be used as a successor to Android
- Redox OS - in dev; no concrete news of mainstream usage plans I know of, but has some mindshare among developers
- Minix 3 - used in production; infamously by Intel in their IME
- There is a per-thread IPC zone of 0x100 bytes. When doing IPC, the request is serialized and put into this. If bigger data than 0x100 bytes is necessary, pointers are passed around, and the Kernel maps it into the process servicing the call. - svcSendSyncRequest is used to call an IPC. It is a synchronous API that will block until the process servicing the call replies to it. - svcReplyAndReceive is used to receive an IPC request and reply to a request, and then wait until a new one is received. The syscalls are "merged" into a single one to avoid the syscall overhead: Almost all svcReply will be followed by an svcReceive, so merging them into a single call makes a lot of sense.
You can find more information about the SVCs at [1] and the IPC layout at [2].
[0] Preempting the "I thought the switch used BSD": wikipedia was wrong, the OS is completely custom, and the kernel is tailor-made. [1] http://switchbrew.org/index.php?title=SVC [2] http://switchbrew.org/index.php?title=IPC_Marshalling
A little note about this: Horizon/NX actually traces back to the Horizon OS on the Nintendo 3DS. The IPC marshalling was significantly more simple back then[1]. In all honesty, I'm not sure what made Nintendo thing the IPC marshalling on the NX was a good idea; to me it just looks like a hastily-designed mess (cf. "This one is packed even worse than A, they inserted the bit38-36 of the address on top of the counter field." on the [2] page linked by the parent comment). However, the NX incarnation was designed with "naturally" wrapping C++ methods in mind and it does a fairly decent job at that.
[1] https://www.3dbrew.org/wiki/IPC#Message_Structure
(Shoutouts to 3dbrew actually realizing that HTTPS is a thing that exists and maybe should be deployed.)
It's a low level RPC mechanism, it does reschedule to the new process immediately without a trip through the scheduler when it's used, it has similar blocking semantics, etc.
It's also worth following the "bus1" work for linux which may end up being quite similar as well.
The most striking thing about running QNX on the desktop was the absolutely consistent response. It doesn't page, so everything is in memory. Going back to Linux felt so laggy.
You pay about a 10%-20% overhead cost for all that interprocess communication. It's not a big deal on modern processors, because when you send a message, the receiving process is running on the same CPU and the data is usually in L1 cache since the sender just put it there. So copying is cheap.
Incidentally, all the Boston Dynamics robots run QNX. They're coordinating all those limbs and valves from one CPU. It's not distributed; that would be too uncoordinated. Valve update is at 1KHz; balance update is at 100Hz.
Was it ever really open? I can't find copies of any version (regardless of how old)
QNX is doing well in automotive.[2] QNX is the part of Blackberry that's making money.
[1] http://www.qnx.com/news/pr_2471_1.html [2] http://canada.autonews.com/article/20180622/CANADA/180629921...
QNX does include features to control this but you have to know enough about it to realize you want them. And POSIX priorities are not enough to prevent this from happening because they are solving a different problem.
You might find it useful in servers where controllable latency is more important than responsiveness, but I wouldn't use it in a user-driven workload like a desktop OS without very carefully configuring it. Out-of-the box it can be very unstable.