Question - why the lock on the client isn't async

[eyalsatori]

Hi ,

Trying to understand why you choose to use use std::sync::RwLock, instead of async lock like tokio::sync::RwLock.

The impact of sync lock on async program is very big . it's will hold system-thread , and block all other tasks that running on this thread.

change to async look will cause some api changes (sync functions will became async) , but if you ok with such change I will work on PR.

[eyalsatori]

Opened a PR if it's relevant #22

[ant32]

https://docs.rs/tokio/1.14.0/tokio/sync/struct.Mutex.html#which-kind-of-mutex-should-you-use

[kayleg]

As the article @ant32 linked states:

The feature that the async mutex offers over the blocking mutex is the ability to keep it locked across an .await point. This makes the async mutex more expensive than the blocking mutex, so the blocking mutex should be preferred in the cases where it can be used. The primary use case for the async mutex is to provide shared mutable access to IO resources such as a database connection. If the value behind the mutex is just data, it’s usually appropriate to use a blocking mutex such as the one in the standard library or parking_lot.

I chose the blocking RwLock because we only need to protect/share the credential data stored in the client during the construction of request and then we can release the lock.

[kayleg]

If you can provide a benchmark showing the tokio::sync::RwLock improves throughput I would be happy to work on a transition plan for the needed api changes.

[eyalsatori]

Ok , I learned something new , thanks :)