riyaneel

Just having a bad english. But yes, the application logic is where the vulnerability can occur. I am adding support for seccomp-BPF but this is complicated for managed runtimes like Go, JVM, Node, Python.

Exactly, the application logic is the target. Actually doing seccomp bpf base but for managed bindings (Java, Node, Go, ...) add a lot of complexity....

Im currently adding doc, but 128b alignas are for the Adjacent Cache Line prefetcher and avoid to silence the MESI protocol

Fair point on the head cache line. Tachyon's target is cross-language zero-copy IPC, not squeezing the last nanosecond out of a pure C++ ring. Different tradeoff.

You're right on the MPSC point, the ADR overstates it. Aeron's claim-based approach uses a single fetch_add per producer, no retry loop. The real constraints are bounded message size upfront and a caretaker thread for reclamation, not a CAS retry. The wording needs fixing. On the SPSC counter argument, Tachyon already does most of what you describe: inline headers, head/tail on separate 128-byte cache lines, cached tail only reloaded on apparent fullness, tail writes amortized across 32 messages. If you have numbers comparing the single-counter approach against this specific layout I'd be genuinely curious.

Exactly, futexes are only used if the consumer opts-in for the sleep phase. The low-latency hot path uses pure spin mode which completely bypasses kernel and fences.

Tachyon is lock-free and uses a strict alignment to avoid the MESI protocol, but relies on the environment for isolation. You still need core pinning and CPU isolation for true hardware determinism.

Fair point. The real difference is the narrower: with a futex the producer can inspect consumer_sleeping directly in shared memory and skip the FUTEX_WAKE entirely if the consumer is still spinning. With eventfd you need a write() regardless, or you add shared state to gate it, which is essentially rebuilding futex. Same idea but slightly less clean.

Would love to hear the feedback