You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
At the time of writing, the implementation for the io_uring WorkPool backend is fairly simple and centered primarily around the base IoUring API provided by the stdlib; as it stands, this works well insofar as handling IO that can be dispatched to the kernel (which is everything that's required for sending snapshots, and the other responses to GET requests).
As we implement more of the RPC API - in particular responding to POST requests, the actual Remote Procedure Calls -, this may become insufficient, as we will need to dispatch work that isn't based on IO, but on user-space processing specific to each kind of RPC.
Side-Quests
If it so happens that an event loop can be created in such a way that it can be shared easily, readably, and efficiently between a few different WorkPool backends, that would be ideal, but not a requirement.
Non-Goals
We are not crafting a general-purpose or cross-platform event loop; it should remain tightly integrated with io_uring (or for each, whatever other backend we may implement in the future) so as to take full advantage of its abilities, and keep our implementation bespoke and easy to understand.
Goal
The purpose of this issue is to keep track of the work that will go into evaluating whether an extra layer for dispatching both IO and user space processing tasks is necessary, or if we can satisfy all of our requirements using io_uring primitives in some way. This issue may be closed when that is accomplished.
The text was updated successfully, but these errors were encountered:
At the time of writing, the implementation for the io_uring WorkPool backend is fairly simple and centered primarily around the base
IoUring
API provided by the stdlib; as it stands, this works well insofar as handling IO that can be dispatched to the kernel (which is everything that's required for sending snapshots, and the other responses to GET requests).As we implement more of the RPC API - in particular responding to POST requests, the actual Remote Procedure Calls -, this may become insufficient, as we will need to dispatch work that isn't based on IO, but on user-space processing specific to each kind of RPC.
Side-Quests
If it so happens that an event loop can be created in such a way that it can be shared easily, readably, and efficiently between a few different WorkPool backends, that would be ideal, but not a requirement.
Non-Goals
We are not crafting a general-purpose or cross-platform event loop; it should remain tightly integrated with io_uring (or for each, whatever other backend we may implement in the future) so as to take full advantage of its abilities, and keep our implementation bespoke and easy to understand.
Goal
The purpose of this issue is to keep track of the work that will go into evaluating whether an extra layer for dispatching both IO and user space processing tasks is necessary, or if we can satisfy all of our requirements using io_uring primitives in some way. This issue may be closed when that is accomplished.
The text was updated successfully, but these errors were encountered: