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

Move state machine init to after port connections? #537

Open
bocchino opened this issue Nov 20, 2024 · 7 comments
Open

Move state machine init to after port connections? #537

bocchino opened this issue Nov 20, 2024 · 7 comments
Labels
code generation Issues related to code generation proposed feature A proposed new feature

Comments

@bocchino
Copy link
Collaborator

This issue came up in the review of #534. In the current design, state machine initialization occurs during component initialization. Since ports aren't connected at that point, this means that the initial state transition can't invoke output ports, including sending telemetry or emitting events. If we want to relax this restriction, then we will need to change the design.

@bocchino bocchino added the code generation Issues related to code generation label Nov 20, 2024
@bocchino
Copy link
Collaborator Author

this means that the initial state transition can't invoke output ports, including sending telemetry or emitting events

Note that the preferred pattern for telemetry is to store it internally to the component and send it on a schedIn call. So telemetry sending may not be a big limitation here.

@bocchino
Copy link
Collaborator Author

bocchino commented Nov 21, 2024

Per @garthwatney: We can always model an initial state that does nothing except wait for a first RTI from schedIn. At that point everything is up, and the system can go to an initial state that emits an event. This is very clear and explicit.

@bocchino
Copy link
Collaborator Author

@LeStarch Is it OK to close this issue as completed? Resolution:

  1. For telemetry, use the pattern where you store updates in the component and push them out on schedIn.
  2. For events, if you need initial state entry to emit an event, use the pattern described in the comment above.
  3. We will document the limitation as part of Integrate Phase 2 state machines with F Prime #508.

@LeStarch
Copy link
Collaborator

I am not convinced. As a potential user of state machines, I need to do a lot of contortions for what would often be a common pattern.

While I don't think this is blocking work, I still think we should keep it on the roadmap.

@bocchino
Copy link
Collaborator Author

bocchino commented Nov 21, 2024

I need to do a lot of contortions for what would often be a common pattern

What are the contortions? (1) seems like the recommended pattern anyway. (2) seems reasonable to me and not a contortion. You are explicitly modeling the initial phase as a state of the system. To me this approach has advantages over relying on complex hard-wired initialization orders, which can be brittle and hard to remember.

@bocchino
Copy link
Collaborator Author

I'm fine with adopting a wait-and-see approach.

@LeStarch
Copy link
Collaborator

Same here! Let's wait and see what users think.

@bocchino bocchino added the proposed feature A proposed new feature label Jan 7, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
code generation Issues related to code generation proposed feature A proposed new feature
Projects
Status: To do
Development

No branches or pull requests

2 participants