Cool Idea: Cursor Pump to Prevent Buffer Underruns

[bchavez]

Been thinking about Cursor<T> a lot recently.

One of the things I see with the current implementation is, every time the consuming thread reaches zero-buffered items the consuming thread has to:

1. await for the CONTINUE Response if it's not already here (maybe it consumed things pretty fast)
2. If the Response is present, move the response data into a cursor's internal buffer
3. Fire off a CONTINUE if needed.

Essentially, we have to do some extra work every time we underrun the internal cursor buffer.

Not saying it's bad, but if we had a lil micro task that fired from the consuming thread when the internal buffer reached a "low water mark" threshold, the micro task would go out and work with the Connection to pull in cursor items as fast as possible to refill the internal cursor buffer up to a "high water mark" threshold.

Worst case, cons: The consuming thread is just way too fast at consuming cursor items and the server is being a slow poke. Having a system like this would lead to unnecessary overhead with things like ConcurentQueue.

Best case, pros: The consuming thread has very little "cursor maintenance" to do, and is hardly blocked or awaited on.

Maybe we could have the best of both words, two cursor implementations, and let the user pick.

So, when the user calls RunCursor<T> run helper, they can pass a parameter that specifies they want a cool Cursor with a micro task pump:

Query.RunCursor<T>(conn, {the cursor I want is a cursor 
                    with a micro task pump for dis query, and here
                    is the high water mark and low water mark});
                    //hell yeah.

:boom: cool. maybe it doesn't matter to ppl, but still bad-ass cool.

:tulip: :rose: _"Sciuri, sciuri... sciuri di tuttu l'annu ..."_