refactor: change reader's get_range result to be a static future#5755
refactor: change reader's get_range result to be a static future#5755westonpace merged 2 commits intolance-format:mainfrom
Conversation
Code Review: PR #5755 - Static Future for get_rangeOverviewThis PR refactors the Issues to AddressP0 - Potential Bug: SmallReader internal trait not used by outer structIn P1 - Missing
|
Codecov Report❌ Patch coverage is
📢 Thoughts on this report? Let us know! |
…ce-format#5755) This is the first in a set of PRs to add both a new scheduler implementation (a lightweight task-free scheduler) and a new reader implementation (that utilizes I/O uring). The need for this isn't terribly obvious. Instead of... ``` let fut = reader.get_range(...) ``` it would seem we could just do... ``` let fut = async move { reader.get_range(...) }; ``` ...and we will have a static future. Unfortunately, the latter approach changes the semantics somewhat. Instead of calling get_range immediately, it does not call get_range until the future is first polled. This is a problem for the I/O uring reader which needs to immediately push the request into the submission queue (and not wait until polled). Perhaps there is a different solution than this PR but this PR is also not too onerous and does work. --- **This PR was partially created with Claude Opus 4.5. I have reviewed all suggested changes and take full responsibility for them.**
…ce-format#5755) This is the first in a set of PRs to add both a new scheduler implementation (a lightweight task-free scheduler) and a new reader implementation (that utilizes I/O uring). The need for this isn't terribly obvious. Instead of... ``` let fut = reader.get_range(...) ``` it would seem we could just do... ``` let fut = async move { reader.get_range(...) }; ``` ...and we will have a static future. Unfortunately, the latter approach changes the semantics somewhat. Instead of calling get_range immediately, it does not call get_range until the future is first polled. This is a problem for the I/O uring reader which needs to immediately push the request into the submission queue (and not wait until polled). Perhaps there is a different solution than this PR but this PR is also not too onerous and does work. --- **This PR was partially created with Claude Opus 4.5. I have reviewed all suggested changes and take full responsibility for them.**
~~This is still a draft while waiting on #5755 and #5773 This PR adds a new URI scheme `file+uring`. The scheme uses the same local file reader as `file` but has two custom `Reader` implementations that are based on the io_uring API. One of these creates a configurable number of process-wide ring threads and the reader communicates with this thread using a queue. The second assumes that the scheduler and decoder run on the same thread and uses a thread local uring instance. Both are able to saturate up to 1.5M IOPS/s when combined with the scheduler rework. I've tested the thread local variant up to 2M IOPS/s. These numbers are assuming the data is not in the kernel page cache. I've seen results as high as 4M IOPS/s when the data is cached. --------- Co-authored-by: Claude Opus 4.6 <noreply@anthropic.com>
This is the first in a set of PRs to add both a new scheduler implementation (a lightweight task-free scheduler) and a new reader implementation (that utilizes I/O uring).
The need for this isn't terribly obvious. Instead of...
it would seem we could just do...
...and we will have a static future. Unfortunately, the latter approach changes the semantics somewhat. Instead of calling get_range immediately, it does not call get_range until the future is first polled. This is a problem for the I/O uring reader which needs to immediately push the request into the submission queue (and not wait until polled). Perhaps there is a different solution than this PR but this PR is also not too onerous and does work.
This PR was partially created with Claude Opus 4.5. I have reviewed all suggested changes and take full responsibility for them.