action triggering calling process_event to trigger transition

[tylerjw]

I think I'm using this wrong because it is creating huge call stacks. Inside my actions, I'm calling process_event with success or failure events to cause the state to transition. This creates a huge call stack because calling process_event results in the next action being called and the call stack just keeps getting deeper. Is there a better way to architect this behavior?

Idle + async = start_state
start_state + on_entry / long_action
start_state + long_action_success = next_state
start_state + long_action_failure / long_action_retry
...

end of long running action method:
if (success) { sm.process_event(long_action_success{}); }
else { sm.process_event(long_action_failure{}); }

[erikzenker]

If your action is finally calling itself you end up in an endless recursion. Which builds up a huge call stack. You could decouple action call and execution via a thread loop. Boost asio provides with the io_context such a thread loop.

[rezahousseini]

shouldn't there be a process_once function which only processes one event?

[erikzenker]

@rezahousseini hasn't process_event this semantic? But if you call it in a recursion loop then there is nothing sml can do about, or do I oversee something?

[GuiCodron]

The process method exists to enqueue event during action that will then be processed once the first event run to completion has been executed.

Le jeu. 10 sept. 2020 à 15:07, Erik Zenker [email protected] a écrit :

@rezahousseini https://github.com/rezahousseini hasn't process_event this semantic? But if you call it in a recursion loop then there is nothing sml can do about, or do I oversee something?

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/boost-ext/sml/issues/288#issuecomment-690274517, or unsubscribe https://github.com/notifications/unsubscribe-auth/AC3DS4OD2P3MUVJ3CWLOMVLSFDFR3ANCNFSM4IH76Q3A .