Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

bug: Events triggered via sml::back::process<TEvent>() are not processed in parent state #562

Open
rhaschke opened this issue Mar 6, 2023 · 1 comment

Comments

@rhaschke
Copy link
Contributor

rhaschke commented Mar 6, 2023

Expected Behavior

Events not handled in a child state should be handled by the parent state. Duplicate of #400.

Actual Behavior

While this works for events injected via process_event() from the top-level machine, it fails for events triggered by an action via sml::back::process<TEvent>(): https://godbolt.org/z/dnMv1dfa4

@rhaschke rhaschke changed the title bug: Events triggered via sml::back:process<TEvent>() are not processed in parent state bug: Events triggered via sml::back::process<TEvent>() are not processed in parent state Mar 6, 2023
rhaschke added a commit to rhaschke/sml that referenced this issue Mar 18, 2023
While events triggered via `process()` from a sub state are correctly handled
in the parent state, events triggered via `back::process` are not.
Also, the event triggered via `back::process` is not known to the parent machine,
causing a compiler error: `no matching function for call to ‘get_id<int, e2>(...)`
@rhaschke
Copy link
Contributor Author

rhaschke commented Mar 18, 2023

I analyzed this issue a little bit and found that the event triggered via sml::back::processs is injected into the sub state's process queue instead of using the root state's one:

back::process process
return back::process<TEvents...>{sm.process_};
aux::get<get_root_sm_t<TSubs>>(subs).process_.push(event);

A similar issue was resolved in #302 for process, which actually works correctly now.
I added a (failing) unit test in my fork to illustrate the problem.

To resolve that issue here in a similar fashion, one would need to access the root sm in get_arg, which is not available yet. However, instead of applying this kind of fix again, I want to fundamentally question the design:
Why do we need the process_ queue in all sub state machines at all? Doesn't it suffice to have a single one in the root state machine - as we need to process all events from there? All subs could simply have a pointer to that single queue instance, such that we don't need to change API of get_arg.

For deferred events the story is different I think: they should be kept in state-local queues and be processed as soon as the state is left.

J-Meyers pushed a commit to J-Meyers/sml that referenced this issue May 9, 2023
While events triggered via `process()` from a sub state are correctly handled
in the parent state, events triggered via `back::process` are not.
Also, the event triggered via `back::process` is not known to the parent machine,
causing a compiler error: `no matching function for call to ‘get_id<int, e2>(...)`
J-Meyers pushed a commit to J-Meyers/sml that referenced this issue May 9, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant