OLSRT: A C11 Concurrency Runtime with Actors and Event Loop
Discover OLSRT, an open-source Apache-2.0 C11 runtime integrating actors, channels, and an event loop with zero external dependencies.
Stock photo for illustration only, not from the actual event
- OLSRT is an open-source Apache-2.0 C11 runtime bundling actors, channels, and an event loop into a single package.
- Built entirely in plain C11 with zero C++, no garbage collector, and no external dependencies beyond pthreads and standard library.
- Latest update resolves 11 real bugs and adds 22 assertions passing ASan, UBSan, and TSan checks.
- Includes seven self-contained demo programs in demos/ and a Python verify.py script for automated checks.
Four years ago, writing concurrent C code on Linux meant repeatedly building the exact same boilerplate components from scratch: an epoll wrapper, a thread pool, a lock-free queue, a promise type, and a clean shutdown mechanism free of memory leaks. While libraries like libuv solved this successfully for some, most projects ended up reinventing these wheels independently.
OLSRT was built to directly address this fragmentation. It is an Apache-2.0 C11 runtime that packages all of these fundamental primitives into a single ecosystem, backed by a coherent ownership model and a unified event loop tying everything together.
Crucially, the entire runtime is written in plain C11. It contains no C++, no garbage collector, and requires no external dependencies beyond pthreads and the standard library.
Stock photo for illustration only, not from the actual event
The previous release shipped initially without an official test suite and consequently contained eleven genuine bugs. The development team spent a full week writing regression tests before addressing the issues one by one, with ASan, UBSan, and TSan running continuously across every single commit.
The catalog of discovered bugs—including an ASan-only heap-use-after-free and a memory-ordering defect inside a lock-free ring buffer—serves as an invaluable learning resource. The repository now features 22 assertions spanning six test suites, all passing cleanly under -fsanitize=address,undefined and -fsanitize=thread. While this test coverage is modest, it represents the critical boundary between a toy concurrency helper and a runtime reliable enough for production side-projects.
Developing a custom concurrency runtime from scratch in plain C11 presents significant engineering challenges, requiring developers to manually handle memory management and memory ordering without a garbage collector. Adopting rigorous sanitizer tools like ASan, UBSan, and TSan early in the development cycle helps catch elusive multithreading memory bugs that standard testing often misses.
Additionally, the demos/ directory contains seven self-contained small programs. Rather than serving as performance benchmarks, they act as honest verification probes to ensure core primitives function correctly. For instance, Demo 02 pushed 1,000,000 messages through a 1024-slot channel on a 2012-era dual-core 1.7 GHz AMD E2-1800 processor at approximately 386,000 messages per second. Meanwhile, Demo 04 recorded timer drift under two microseconds across six periodic fires, confirming that the primitives behave as advertised.
"The trickiest bug we fixed was a memory-ordering issue in a lock-free ring buffer that only shows up on ARM. Has anyone else written a similar primitive and can share how they tested it?"
OLSRT Developers
The public roadmap is accessible via ROADMAP.md in the repository, and getting started requires just a few standard commands:
- git clone https://github.com/OverLab-Group/OLSRT.git
- cd OLSRT
- make linux
- python3 verify.py
Running verify.py takes about two minutes on a modern laptop, successfully executing all four validation checks or pinpointing the exact failing file. The maintainers welcome further bug reports, particularly those accompanied by an ASan backtrace.
Source: Dev.to
Found something wrong in this article? Report an issue with this article
Comments
Leave a Comment