Remove external disruptor-cpp dependency #45
Description
The C++ EVIO multi-threaded writer (WriterMT / RecordSupply) depends on a custom external fork of disruptor-cpp to implement a very specific pipeline:
- single producer (record assembly)
- M “compression” consumers (fan-out by stride)
- single writer consumer (must see items only after compression stage completed)
This dependency adds build/packaging friction and increases long-term maintenance risk (extra repo, custom fork, toolchain quirks, platform availability). It’s also disproportionate to the small subset of functionality we actually use.
Proposal
Replace the external Disruptor dependency with the small (relatively) internal implementation that provides the same behavior the C++ writer needs.
As I studied the library, no public API changes are required. The change is internal to RecordSupply / WriterMT implementation.
Implementation
Implement a compact “record ring”:
- fixed-size ring buffer (power-of-two sizing)
- single producer: claim → fill → publish
- M compression workers: each processes every Mth record (stride assignment as today)
- writer thread waits until compression workers to keep same frames/events order
- shutdown/abort signaling to wake blocked threads, clean exit, etc.
Implementation use modern standard C++ primitives.
Motivation
Jefferson Lab relies heavily on EVIO. With that, thinking about the next 5-10 years, I would expect halls to migrate to EVIO 6, much more adopt the streaming formats, and increased the use C++ library. Also note, that EIC detector beam tests use EVIO and hopefully this will bring even more attention from many institutions worldwide to how to process EVIO saved data.Thus, I strongly believe, that having a standard, easy-to-build and use modern C++ library is a must for the future of EVIO.
The current C++ codebase mirrors the Java implementation closely, which made sense for initial development. The rare situation happened: tiny group of experts that are proficient in both c++ and java wrote it. Having mirror API is convenient in this case. From the users perspective, C++ users in nuclear physics are usually those who are not proficient in Java and don't want to use it and don't want deal with java. For them it is more imprortant to have modern C++ look and feel with convincing benchmarks and best practices. Currently C++ feels with like writing java with C++ syntax.
This ticket certainly doesn't change this, as it doesnt change API. But this will be the very beneficial first step in terms of how it is tested, how it changes, how it should look like, etc., etc. etc.
Effort
EVIO uses only small subset of of the Disruptor library:
- RingBuffer with single-producer mode only
- Sequence and ISequenceBarrier for coordination
- SpinCountBackoffWaitStrategy (spin 10k times, then block)
- AlertException for shutdown signaling
This is primarily used for multi-threaded compression in RecordSupply
Reimplementing it directly should not be more than couple of hundreds LOCs for the core ring-buffer coordination logic. Utilizing modern c++ stdlib primitives. It is also a good platform to start implemeting C++ tests, benchmarks, etc.