MSM and multithreading. Not clear what pattern to follow.
Hi, I'm trying to use MSM to implement a client server component for my app. The client is broadcasting a msg, that servers in a local network will detect and respond. The client at that point will connect to one of the servers and interact following the network protocol. For the network and threading I'm using boost ASIO. I have 2 submachines that manage one the discovering part, and the other the connection and dialogue with one server part. I found that would be beneficial to run the submachines in one thread managed by an io_context, with the idea of stopping that context to cancel all the asynchronous operations. Unfortunately there are some weird behaviours with submachines, and not getting if I missed the right way of doing things or else. the description of my last stopper is here: https://github.com/boostorg/msm/issues/37 Is anyone able to point me on the right direction? Regards, Andrea
On Mon, 8 Mar 2021 at 15:38, Andrea Fiorito via Boost-users < boost-users@lists.boost.org> wrote:
Hi, I'm trying to use MSM to implement a client server component for my app. The client is broadcasting a msg, that servers in a local network will detect and respond. The client at that point will connect to one of the servers and interact following the network protocol. For the network and threading I'm using boost ASIO.
I have 2 submachines that manage one the discovering part, and the other the connection and dialogue with one server part. I found that would be beneficial to run the submachines in one thread managed by an io_context, with the idea of stopping that context to cancel all the asynchronous operations.
Unfortunately there are some weird behaviours with submachines, and not getting if I missed the right way of doing things or else. the description of my last stopper is here:
https://github.com/boostorg/msm/issues/37
Is anyone able to point me on the right direction?
When I've done this in the past I've had most success by separating out the thread/asio code from the state definitions and storing it in the class that represents the state machine front end. All interaction with Asio takes place by a call to a method on the FSM. In this way you can insulate the state machine transitions from issues caused by threads or asynchronous callbacks by ensuring that every call to `process_event` happens in a function being executed by the strand. It also eases state transitions if you don't make the state machine worry about waiting for completion handlers to execute. You can keep a "generation counter" or "token" in the handler so that it becomes a NO-OP if the async operation is out of date. A partial example on godbolt: https://godbolt.org/z/TzY17h
Regards, Andrea _______________________________________________ Boost-users mailing list Boost-users@lists.boost.org https://lists.boost.org/mailman/listinfo.cgi/boost-users
-- Richard Hodges hodges.r@gmail.com office: +442032898513 home: +376841522 mobile: +376380212
participants (2)
-
Andrea Fiorito
-
Richard Hodges