Implementing async flock

[jbaublitz]

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?

[IvanUkhov]

Too bad no answers. Have you gained any experience with this by now and could perhaps give some recommendation? Thank you!