How about change async client mutex from std::sync::mutex to tokio::sync::mutex?

[jokemanfire]

Which feature do you think can be improved?

streams need aync lock write,so use tokio to decide the schedule.

How can it be improved?
tokio::sync::mutex

Additional Information
..

Before raising this feature request

..

[wllenyj]

In what case does tokio Mutex need to be used?
If there's no clear usage case, I'd recommend leaving it as is.

[jokemanfire]

while async request and disconnect func , these two operations will change the hashmap streams . If requests occur much more one of them ,a thread will hold for long time. use tokio::sync::mutex will release the thread's cpu while there's no chance to lock the hashmap.

[wllenyj]

hold for long time ?
Are you sure you have read the tokio mutex documentation which-kind-of-mutex-should-you-use
?

[jokemanfire]

If I misunderstand . The tokio.sync:mutex may be greater for IO intensive ?
`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.

Note that, although the compiler will not prevent the std Mutex from holding its guard across .await points in situations where the task is not movable between threads, this virtually never leads to correct concurrent code in practice as it can easily lead to deadlocks.`

I just think the in the async status ,the tokio::sync::mutex may be greater?

[jokemanfire]

That's just my opinion may not correct .
In Tokio runtime, using asynchronous tokio:: sync:: Mutex may have slightly lower performance compared to synchronous std:: sync:: Mutex, but it is designed specifically for asynchronous environments and is more suitable for use in Tokio.
Usage scenario: std:: sync:: Mutex may cause worker threads of Tokio to block, thereby affecting the performance of the entire Tokio runtime. And TikTok:: sync:: Mutex is designed to avoid this situation and is more suitable for use in scenarios that require asynchronous operations.