All I Want is a Shared Context

There already exists a shared context and that is the OS environment, or we could argue the internet as a whole is also a shared context.

I envisioned it as a way to send messages to programs, but every program could see and react on the message send to the program because it was passed through the shared context. Yes it’s an event bus similar to Kafka or RabbitMQ

But they are mostly created for distributed programs that do not run on the same local machine. The sad part is there exists multiple ways we can send events to processes, but there are cumbersome to use.

But Why?

I am fascinated by the human body and nature in general. The way so many different substances circulate throughout our body is incredible, while cells don’t share their own space, each has a membrane holding something and guarding that not everything goes in. Still our body as a whole as a fast interconnected circular system where at various stages multiple substance are in the same place, our blood, stomach, mouth, etc. It’s inhabited with many different kinds if organism that all interact with each other.

These interactions are not encapsulated but instead are observable, often its observed by others via markers like on part of your body reacting to a higher level of blood sugar. Here blood sugar is the marker.

Most programming system don’t really allow for such markers even though they would be quite convenient to use.

Communication can be explicit, talking to each other directly or explicit observing each other.

I simply want to bring this idea to a more viable state. Where all different kinds of programs can better react on each other and talk to each other more efficient.

Exploring IPC

Our goal is to have a fast communication between multiple programs where multiple programs can read and write to. The first thing that comes to my mind is a message queue. Having multiple readers is seldom a problem, multiple writers is definitely a problem.

The question now is how should this message queue look like? We now that it needs to support local processes first we need low latency and “high enough” throughput. We want to make it possible to send many small messages if the latency is too high it will become fast the main bottleneck in an application loop. This is regarding both reading and writing.

Sadly all things in life is a trade-off we cannot make the communication free. Hopefully we can make it cheap enough.

Cutting to the Chase

In my testing I found out that any IPC mechanism that needs to touch the kernel and does a context switch to the kernel has such an incredible latency cost. That it will always dominate the overall latency for many small messages.

There is only one IPC mechanism that does not result in kernel calls for reading and writing. And that is shared memory.

Here the biggest problem is organizing readers and writers so they don’t block each other and trash performance. Also, you can imagine what other problems might happen when we have 30 readers, 5 writers.