TelluIoT / ThingML

The ThingML modelling language
https://github.com/TelluIoT/ThingML
Apache License 2.0
101 stars 32 forks source link

Defer #242

Open brice-morin opened 5 years ago

brice-morin commented 5 years ago

(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.

brice-morin commented 5 years ago

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)?