Hey,

I wanted to replace a worker/dispatcher logic orchestrated with channels with this but I notice a high CPU usage so the lib is probably not adapted for such usage.
I'd like the have workers waiting for more work to process such as:

 for {
        work := gringo.Read()
        // ... process the work
    }

but if I understand it well, it'll release the thread and continue to loop, hence a 100% CPU usage.
Can you think of a way to block instead, waiting for more work to process?
Many thanks!

Hi @textnode and thanks so much sharing this code!

I also got really interested in the disruptor pattern after reading about it somewhere, and was happy to find this Go implementation.

I've been thinking it might speed up pipelines created with my experimental flowbase and scipipe libraries (perhaps mostly relevant to flowbase), so I set out to experiment a little, with a slightly modified version of gringo, results of which is available here.

It is a pretty CPU heavy pipeline, but I still manage to get speedups, although mostly for 1 or 2 CPUs, as can be seen in the example output (the times vary a bit, so one should really do some averaging).

If you are interested in having a look whether I do any silly mistakes, my slightly adapted version of gringo is available on these lines in the disruptor version of the pipeline.

lastCommittedIndex should be guarded by an atomic lock.

Can you explain the meaning of padding, thank you