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

Should port values be persistent across tags? #1661

Open
cmnrd opened this issue Mar 17, 2023 · 1 comment
Open

Should port values be persistent across tags? #1661

cmnrd opened this issue Mar 17, 2023 · 1 comment
Labels
language Related to the syntax and semantics of LF question Further information is requested

Comments

@cmnrd
Copy link
Collaborator

cmnrd commented Mar 17, 2023

In the C target, port values with simple types are persistent across tags (i.e. if a reaction reads a port that it is not present at the current tag, it reads the value that was written last). This is the case because invalidating a plain value like an int is simply not possible in C. While earlier this was treated as an implementation detail, the C target now seems to treat this as a feature and also some examples (see https://github.com/lf-lang/examples-lingua-franca/blob/main/C/src/rosace/README.md) depend on this "feature". However, I don't think we ever had a full discussion about whether we should change the semantics of ports in LF and whether this should also apply for token types (see also #1653). I think we should reach a conclusion in this question and document it accordingly.

As I see it, the main argument for persistent ports is that it is easier to handle situations where the tags of inputs do not always align perfectly. If we have a reaction triggered by two ports, and we always want to use the latest observed value even if the port is not present, we would need to introduce two state variables and manually cache their values in the reaction. With persistent ports, no manual caching is needed as it is a built-in feature.

To me, this is an appealing argument. Also, from an implementation point of view, I don't see big issues. In fact, switching to persistent ports should be a trivial change in the C++ target. That said, I also do see problems and open questions that I am not sure if everyone is aware of.

  • What should be the initial value of the port? The C target seems to just leave them uninitialized. This, however, only works for trivial types. How should we handle this problem in general? Should there be an LF initializer syntax for ports, similar to the one we have for state variables?
  • The lifetime of objects matters. With persistent ports, however, it becomes unpredictable when objects will be destructed. Currently, all ports are cleared at the end of the tag, which means that also all values that are not referenced anymore can be destructed and the memory can be freed. With persistent ports, we will keep objects in memory that most often will not be used again.
@cmnrd cmnrd added question Further information is requested language Related to the syntax and semantics of LF labels Mar 17, 2023
@edwardalee
Copy link
Collaborator

The C target implements persistent ports for all data types, not just simple types.

The ports are not exactly "uninitialized". The memory corresponding to the type is allocated and filled with zeros. However, I agree that allowing an initializer syntax like that of state variables would be good.

@cmnrd cmnrd linked a pull request Mar 24, 2023 that will close this issue
6 tasks
@cmnrd cmnrd removed a link to a pull request Mar 24, 2023
6 tasks
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
language Related to the syntax and semantics of LF question Further information is requested
Projects
None yet
Development

No branches or pull requests

2 participants