iceoryx2 v0.9 released: Fast and Robust Inter-Process Communication (IPC) Library (ekxide.io)
from elBoberido@programming.dev to programming@programming.dev on 19 May 11:07
https://programming.dev/post/50633812

Hello everyone

We released iceoryx2 v0.9 tonight. With the release, we are pushing more and more iceoryx2 into the embedded world. We have written a test runner that runs on std and no_std environments, stabilized the decentralized recovery, and added a ton of quality of life improvements.

For those who haven’t heard of it yet: iceoryx2 is a zero-copy inter-process communication library.

The basic idea is: instead of serializing data, copying it through sockets, pipes, message queues, or some broker process, iceoryx2 lets processes communicate via shared memory. That makes it useful when you care about latency, throughput, or moving large amounts of data between processes without wasting CPU cycles on copies.

It supports C, C++, Python, Rust, and C#, and runs on Linux, macOS, Windows, FreeBSD, and QNX, with experimental support for Android and VxWorks.

It is not limited to plain pub/sub either. iceoryx2 supports publish-subscribe, events, request-response streams, and a blackboard pattern, which is basically a key-value repository directly in shared memory.

The architecture is fully decentralized: no central broker, no daemon that everything depends on, and no single process that becomes the obvious bottleneck or failure point.

Happy to answer questions about the release, the no_std work, or zero-copy IPC in general.

#programming

threaded - newest

kibiz0r@midwest.social on 19 May 14:30 collapse

Well, you offered and I’m curious, so here goes.

I know next to nothing about low-level code, but I do know a bit about distributed systems…

For me, if I wanted to efficiently allow multiple concurrent components to read and write a shared data source, my mind goes straight to CRDTs.

How does the blackboard system compare to using CRDTs? Would CRDTs even be useful in these low-level contexts?

(I’m thinking maybe too much coordination overhead for a relatively rare configuration of readers+writers? And also, CRDTs tend to be more useful when you want to be able to survive long or frequent communication partitions, which is not the typical environment for local IPC.)