Owned Buffers#9
Open
supernomad wants to merge 3 commits into
Open
Conversation
This change set is required because io_uring under the hood is completion based, as opposed to intent based like epoll/kqueue/etc this means that the io_uring subsystem actually is what is reading/writing to the buffers specified to calls like recv/send. Without io_uring owning the buffers in use, there is a possibility that the future that kicked off the I/O is dropped (including the buffer) while io_uring is writing/reading to/from it. This would lead to very very bad things and undefined behavior. Since we currently can't express the lifetime constraints we really need via the Rust type system. The only way to guarantee soundness here, is to own the buffers in question end to end. With the above said, this isn't all that big of a deal in the end, the system always returns the buffers in use, and the ergonomics can be greatly increased with proper helpers. Also this paves the way for Recv[Msg]Multi setup and provided buffers for further enhancements.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
This change set is a large very breaking change to the API's. The TL;DR is that this moves
libuioto owned buffers for all I/O calls, this means instead of using say a&mut [u8]or a&[u8]you have to use aVec<u8>this is for both send and receive.The long story here is that because
io_uringis completion based and actually reading/writing to the buffers, the only way to guarantee that all the reads and writes are sound, is to own the actual data. Otherwise its possible for a future and its associated buffer to be dropped while theio_uringkernel threads are interacting with the supplied pointer. Unfortunately as of the latest rust there is no other way in the type system to enforce that the buffers remain live and valid without owning the vector itself inside theio_uring. This ensures that even if the future is dropped the actual buffer will remain valid until after theio_uringis done using it and it can then be safely freed or reused as needed.However though this is a large change it paves the way for highly efficient memory utilization and the various other optimizations that
io_uringbrings to the table like theRecv[Msg]MultiI/O operations and provided buffers for automatic buffer selection by the kernel.This is just the first step along the way, and the ergonomics of this very ingrained API can and will be greatly improved, likely with the addition of new structures and helpers.