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
I'm currently working to implement an async version of flock for use in a storage project. Rust's mutability guarantees are good for memory safety, but I'd also like to add device locking so that when I implement multithreading, the tasks in the daemon don't cause data corruption on disk. flock seems to be the best way to do this on Linux, and so I'm looking to make flock async.
I've taken a look at how data structures like AsyncFd and the IO driver work and it appears a lot of this relies on mio to notify the IO driver when an evented structure is ready for reading. Because file descriptors and file descriptor-based structs can interface easily with epoll, this seems to make it relatively easy to notify the IO driver when the file descriptor is ready for reading or writing. In the case of flock, however, I don't think there's any kind system queue based event-driven way to notify the IO driver when flock can acquire a file lock on the device and this leaves me with the question of what the best way to handle this would be.
I can see two options:
Spawn a blocking task for the blocking flock call and notify an asynchronous task that I create when the flock call has returned.
Poll periodically with a nonblocking flock call.
The first option seems to be better in this case because, although it requires a blocking task, it is event driven and will cause the asynchronous tasks to proceed as soon as the lock has successfully been acquired.
The second option seems like it would result in either a lot of unnecessary attempts to acquire a lock in a loop, or a wait time that could potentially slow down the progress of the lock acquisition if it is too high.
Do you have any feedback on the best way to make this work in the context of tokio?
This discussion was converted from issue #3148 on November 17, 2020 17:58.
Heading
Bold
Italic
Quote
Code
Link
Numbered list
Unordered list
Task list
Attach files
Mention
Reference
Menu
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
-
I'm currently working to implement an async version of flock for use in a storage project. Rust's mutability guarantees are good for memory safety, but I'd also like to add device locking so that when I implement multithreading, the tasks in the daemon don't cause data corruption on disk. flock seems to be the best way to do this on Linux, and so I'm looking to make flock async.
I've taken a look at how data structures like
AsyncFd
and the IO driver work and it appears a lot of this relies on mio to notify the IO driver when an evented structure is ready for reading. Because file descriptors and file descriptor-based structs can interface easily with epoll, this seems to make it relatively easy to notify the IO driver when the file descriptor is ready for reading or writing. In the case of flock, however, I don't think there's any kind system queue based event-driven way to notify the IO driver when flock can acquire a file lock on the device and this leaves me with the question of what the best way to handle this would be.I can see two options:
The first option seems to be better in this case because, although it requires a blocking task, it is event driven and will cause the asynchronous tasks to proceed as soon as the lock has successfully been acquired.
The second option seems like it would result in either a lot of unnecessary attempts to acquire a lock in a loop, or a wait time that could potentially slow down the progress of the lock acquisition if it is too high.
Do you have any feedback on the best way to make this work in the context of tokio?
Beta Was this translation helpful? Give feedback.
All reactions