Basically my situation is that I have a struct that hold information that some futures will read from and a few futures will write to. Using a RwLock seems approipriate, I think. However, if I understand tokio correctly using the blocking .read() or .write() on the RwLock would halt the entire program if any other future holds a (writing) lock, unless I spawn futures on different threads. Right?
So the solution would be to spawn a future that tries to read/write on the RwLock by using the try_read() and try_write() methods and if a lock can’t be acquired, the future should return Ok(Async::NotReady). This will tell the event loop to leave this future and come back to it later, maybe after executing some other futures that have been spawned unto the event loop. (Am I still correct?)
Now there is one thing that’s worrying me. That is, if I try to acquire a write-lock on my RwLock, but someone else is reading it, the future trying to get the lock will have to wait. But what happens if during this time, another future gets a read lock before the first one dropped the lock and then another one gets a write lock before the second one drops it and so on… I know this might be rare, but I expect many readers. Could this mean that a writer could have to wait indefinatly to get a lock?
The solution I can think of is to make a struct wrapping the RwLock and having a (atomic?) bool that indicates if a writer is waiting. If a writer is waiting, no new read locks can be acquired. Once the write lock has been given and then dropped the bool goes back to false. Is this necessary? Or is this maybe how the RwLock already works?
Wow, that was a lot of thoughts and questions… If you have an answer for any of my questions, please don’t hesitate and help me out, any help would be greatly appreciated!
P.S. Do you think we can expect the futures::sync module to get a RwLock and more tools in the (near) future?