On 13/04/2022 20:15, Markus Bonk wrote:
A specific onread handler which is initially running on the stream strand needs to read another value from the websocket server to proceed. It sends a message and then waits on a future.
This deadlocks the websocket communication.
Don't block in asio handlers. Async goes all the way up and down. Prefer using something that is better than a future (like another asio async method); but otherwise try registering a callback/then on the future instead of waiting on it. Perhaps look into Boost.Fiber and its coroutine-style futures, which are nicer for asynchronicity than thread-based futures. (Though that may not help you unless you're writing fibers all the way down too.)
If instead of a strand a mutex were being used could unlocking the mutex before sending the message after the data that needs to be protected / requires synchronization has been already acquired and the resources would be available for the next handler.
You should never hold any kind of mutex across an external or long-running call (unless protecting that is the entire point of the mutex, or it's part of a mutex-aware atomic pattern like with condition variables); they should be short-lived to reduce contention. The same applies to asio handlers. And don't even think about trying to externally unlock a mutex that another thread owns, even if you "know" it's blocked.