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
(Mentionned in #202, but I feel it needs its own issue)
Let's say I have a client:
thing Client {
...
p!m1(...)
p!m2(...)
...
}
And a server:
thing Server {
...
state A {
transition -> B
event p?m1 //we process m1, and go to state B
}
state B {
transition -> C
event p?m2 //we process m2, and go to state C
}
state C {...}
...
}
Well... that works as expected. Now if the server looks like this:
thing Server {
...
internal port ip {
sends m3
receives m3
}
...
state A {
internal event p?m1 //we process m1, and eventually send m3 on the internal port
action ip!m3(...)
transition -> B //m2 cannot be handled now, so it is just lost, but we can process m3 and go to state B
event ip?m3
}
state B {
transition -> C
event p?m2 //m2 has been lost, and we will not reach state C
}
state C {...}
...
}
This does not work anymore. Of course, we can refactor the whole protocol, so that server can notify when m1 has been processed, so as the client waits and then sends m2..... But this means we have to refactor the client just because of an implementation detail within the server. The client just want to send m1 and m2, and does not care whether the server uses internal ports or not...
This could be solved by allowing state A to defer message m2, so that it can be processed later on by state B.
The text was updated successfully, but these errors were encountered:
Note that the @sync_send "true" annotation on the internal port solves the problem... for the compilers supporting it (C compilers, Node.JS)... Is there any plan to support this annotation in all compilers (Java, Go)? And make that annotation a concept (like a modified on the port definition)?
brice-morin
added a commit
to SINTEF-9012/thingml-diversifier
that referenced
this issue
Sep 4, 2018
(Mentionned in #202, but I feel it needs its own issue)
Let's say I have a client:
And a server:
Well... that works as expected. Now if the server looks like this:
This does not work anymore. Of course, we can refactor the whole protocol, so that server can notify when m1 has been processed, so as the client waits and then sends m2..... But this means we have to refactor the client just because of an implementation detail within the server. The client just want to send m1 and m2, and does not care whether the server uses internal ports or not...
This could be solved by allowing state A to defer message m2, so that it can be processed later on by state B.
The text was updated successfully, but these errors were encountered: