Am I missing something here or does the BlockingRingConsumer not actually block? And worse doesn't it just return garbage if poll is called without first checking availableToPoll?
The example sure looks like it... https://github.com/coralblocks/CoralRing/blob/main/src/main/...
Which if so isn't this like 1/4th a library for doing IPC? It doesn't seem to do much itself
You are never supposed to call poll() without first calling availableToPoll(). How can you poll something if you don't know if there is something available to poll? This is very different than a ConcurrentLinkedQueue where you can call poll() on an empty queue and get a null to indicate that the queue is empty. Also because the ring is a circular queue, you have to know what you can safely poll before polling. That's all done through availableToPoll().
NOTE: By garbage here I don't think you are talking about GC garbage.
counterexample: you can call ::poll(2) if there isn't anything to available. It will either block or return as desired. That's literally what I would expect a poll function to do: check if something is available; c.f. busy-polling.
Maybe it is a language difference?
Polling, as a term, already generally means asking if there is anything ready. The library might instead have had a poll() to indicate readiness and an unsafeTakeReadyBatch()/releaseBatch() or similar to handle the low level receipt primitives. Or you could even have had a checkForReady() and left poll() to implement a generic version of your busy waiting example, polling with a given sleep and timeout until items were ready, as a convenience for the user.
It's fine as is, of course, as you document expected usage quite well.
So are you saying that POLL was a bad choice of name because polling means "check if there is something available and if there is get it"?
What would be a better name? How about availableToFetch and fetch? Any other better idea?
I don't like remove because you are not actually removing the object from the ring.
A much better name would have been FETCH and not POLL
We'll be changing everything from poll to fetch in the next version => availableToFetch() and fetch()
availableToPoll() is now availableToFetch()
poll() is now fetch()
peek() is now fetch(false)
Note that fetch() == fetch(true)
Which means it doesn't block...
Blocking means the call itself doesn't return until there's data available. This is a completely non-blocking API. Which is fine, it's just very wrongly named in that case.
But that also means I don't really know why there's both "non-blocking" and "blocking" variants at that point if blocking isn't an option at all in the first place.
For the non-blocking ring, the producer never blocks on a full ring. It overwrites the circular ring. The consumer can still block on an empty ring.
So to make it clear:
Blocking ring => producer and consumer can block/wait
Non-Blocking ring => producer never blocks and consumer can still block on an empty ring. Consumer can also fall behind too much and disconnect.
And given these are designed for "ultra-low-latency" systems, I don't think that's a big problem because the best blocking strategy is probably just to spin.
It would be nice if the docs were nicer though, considering this is a paid product...
You busy spin when blocking (fastest) or you can use a WaitStrategy from https://www.github.com/coralblocks/CoralQueue. You can see an example here: https://github.com/coralblocks/CoralQueue/blob/main/src/main...
> And given these are designed for "ultra-low-latency" systems, I don't think that's a big problem because the best blocking strategy is probably just to spin.
If you have an isolated and dedicated CPU core for your thread, that's correct. Busy-spinning is the fastest/best strategy.
> It would be nice if the docs were nicer though, considering this is a paid product...
CoralRing and CoralQueue are open-source and free at GitHub. There are also a lot of documentation and explanations on the GitHub README.me page (front page). The code has also a lot of comments.
Regarding the docs, I was only looking at CoralRing, and it looks like CoralQueue has some additional documentation that applies to CoralRing as well. After reading through them everything makes a lot more sense.