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
Basically wait a week or so for 0.6.0 release of https://github.com/asomers/futures-locks that will use tokio 0.2.0.
Why we want to change it to RwLock rather than Mutex? As there are way many more reads of the data compared to writes. It is read every single client request (for EVERY client) while it is written to only once per single client - during registration. So that would be a significant performance gain.
Edit: This issue refers to uses in sfw-provider as well as in nym-client
The text was updated successfully, but these errors were encountered:
Future note to whoever is going to be implementing this. tokio::sync::RwLock (from what I've tried) does not seem to have an easy access to poll method - it might be problematic if for some reason we wanted that. It might be worth to instead wait for proper futures::lock::RwLock (as with their current futures::lock::Mutex
jstuczyn
changed the title
Change Mutex on ClientProcessing data to RwLock once library updates
Once implementation is available, wherever appropriate, replace futures::lock::Mutex with futures::lock::RwLockJan 23, 2020
Basically wait a week or so for 0.6.0 release of https://github.com/asomers/futures-locks that will use tokio 0.2.0.
Why we want to change it to RwLock rather than Mutex? As there are way many more reads of the data compared to writes. It is read every single client request (for EVERY client) while it is written to only once per single client - during registration. So that would be a significant performance gain.
Edit: This issue refers to uses in sfw-provider as well as in nym-client
The text was updated successfully, but these errors were encountered: