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.
_______________________________________________
Boost-users mailing list
Boost-users@lists.boost.org
https://lists.boost.org/mailman/listinfo.cgi/boost-users
