You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
The text was updated successfully, but these errors were encountered:
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.
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.
The text was updated successfully, but these errors were encountered: