Re: Unlock / free a boost::asio::strand in beast?

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.