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
Right now, this library is heavily dependent on the tokio implementations of RwLock. This is not necessarily a bad thing, but one of the huge optimizations that is possible (in theory) in this system would be the introduction of Hybrid Latches/Locks, and tokio obviously does not provide this data structure.
See this paper for more information about the hybrid latches, as well as a synchronous implementation of them in Rust here.
I'm not sure what a user-facing API for this would look like, so this is an open question. Ideally, we would abstract away the unsafe, but I'm not sure that is possible. Since we know that the data is always 4kb of bytes there might be a way to fall back to a blocking version without making it unsafe...
The text was updated successfully, but these errors were encountered:
Right now, this library is heavily dependent on the
tokio
implementations ofRwLock
. This is not necessarily a bad thing, but one of the huge optimizations that is possible (in theory) in this system would be the introduction of Hybrid Latches/Locks, andtokio
obviously does not provide this data structure.See this paper for more information about the hybrid latches, as well as a synchronous implementation of them in Rust here.
I'm not sure what a user-facing API for this would look like, so this is an open question. Ideally, we would abstract away the
unsafe
, but I'm not sure that is possible. Since we know that the data is always 4kb of bytes there might be a way to fall back to a blocking version without making itunsafe
...The text was updated successfully, but these errors were encountered: