Unlock / free a boost::asio::strand in beast?
Hi, The application is using beast / websockets to communicate with a websocket server. 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. 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. Is there any way of 'unlocking' the strand i.e. setting the state of the handler's thread so that 'isrunning_on_strand' = false and the stream can continue servicing the incoming messages? Thanks for any pointers. Markus ________________________________ Markus Bonk Senior Software Engineer [cid:3dconnexion_bd84aa85-40b4-4789-87b1-4c8f703d9ae6.gif] Clarita-Bernhard-Str. 18 81249 M?nchen Germany markus_bonk@3dconnexion.commailto:markus_bonk@3dconnexion.commailto:%7BE-mail%7D www.3dconnexion.comhttp://www.3dconnexion.com Gesch?ftsf?hrer: Antonio Pascucci Sitz der Gesellschaft: M?nchen Registergericht: M?nchen HRB 99232 This email and any files transmitted with are from 3Dconnexion GmbH. The contents of this email and any attachments are confidential to the intended recipient. They may not be disclosed to or used by or copied in any way by anyone other than the intended recipient. If this email is received in error, please contact 3Dconnexion GmbH by calling +49 89 8974542-0 and then delete it. Please note that neither 3Dconnexion GmbH nor the sender accepts any responsibility for viruses and it is your responsibility to scan or otherwise check this email and any attachments. Any opinion expressed in this email are those of the individual and not necessarily those of 3Dconnexion GmbH. 3Dconnexion GmbH processes and stores for commercial purposes your personal data, collected upon your consent, in accordance with its privacy policy available at https://www.3dconnexion.eu/privacy.html, which has been drafted in accordance with Regulation (EU) no. 679/2016 and all applicable local data protection laws and regulations of the countries where the company operates. To revoke your consent or exercise all your rights with regards to personal data, please contact us at privacy@3dconnexion.commailto:privacy@3dconnexion.com.
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.
participants (2)
-
Gavin Lambert
-
Markus Bonk