31
edits
IPDL/Getting started: Difference between revisions
Jump to navigation
Jump to search
Clarifications about IPDL state machine semantics
m (→Basic messages) |
(Clarifications about IPDL state machine semantics) |
||
| Line 375: | Line 375: | ||
The astute reader might question why IPDL includes the word "protocol" when all that has been introduced so far are unstructured grab-bags of messages. IPDL allows protocol authors to define the order and structure of how messages may be sent/received by defining protocol ''state machines'' (finite state machines). | The astute reader might question why IPDL includes the word "protocol" when all that has been introduced so far are unstructured grab-bags of messages. IPDL allows protocol authors to define the order and structure of how messages may be sent/received by defining protocol ''state machines'' (finite state machines). | ||
IPDL parent and child actors | [Note that the state machine portion of the IPDL compiler is not complete as of this writing, 22 October 2009. IPDL code for state machines is accepted by the compiler, but it does not affect the generated C++, yet.] | ||
IPDL parent and child actors communicating via a protocol are paired. Each actor in the pair follows the same state machine. The pair attempts to keep their single collective state synchronized. Though, it is possible that the parent and child actors may be momentarily out of sync while messages are transmitted. | |||
IPDL (arbitrarily) requires state machines to be defined from the perspective of the '''parent''' side of the protocol. For example, when you see the <code>'''send''' Msg</code> syntax, it means "when the parent actor sends Msg". | |||
The following example shows one such state machine for the Plugin protocol. | The following example shows one such state machine for the Plugin protocol. | ||
| Line 407: | Line 411: | ||
}; | }; | ||
There are three new syntactic elements, above. First are "state declarations": the code <code>'''state''' FOO:</code> declares a state "FOO". (States are capitalized by convention, not because of syntactic rules.) The first state to be declared is the protocol's "start state"; when an actor is created, its initial state is the "start state." | |||
The second new syntax | The second new syntactic element is the ''trigger''. The syntax <code>'''send''' MsgDecl</code> defines a trigger for a state ''transition''; in this case, the trigger is <code>'''send'''</code>ing the async or sync message "MsgDecl." The triggers are: | ||
# <code>'''send'''</code>ing an async or sync message | |||
# <code>'''recv'''</code>ing an async or sync message | |||
# <code>'''call'''</code>ing an RPC | |||
# <code>'''answer'''</code>ing an RPC | |||
'''Aside''': this is why actor ctors/dtors act like normal messages, with directions etc.: this allows them to be checked against the protocol state machine like any other message. | '''Aside''': this is why actor ctors/dtors act like normal messages, with directions etc.: this allows them to be checked against the protocol state machine like any other message. | ||
The third new syntax is <code>'''goto''' NEXT_STATE</code> | The third new syntactic element is a state ''transition''. The syntax is: <code>'''goto''' NEXT_STATE</code>. When the trigger preceding this transition occurs, the protocol actor's internal state is changed to, in this case, "NEXT_STATE." | ||
Another example state machine, for PluginInstance, follows. | Another example state machine, for PluginInstance, follows. | ||
| Line 438: | Line 446: | ||
Note: | |||
* | * The following points will apply when the IPDL compiler fully supports states. It is incomplete as of this writing, on 22 October 2009. | ||
* | * Protocol state machines are optional, but strongly encouraged. Even simple state machines are useful. | ||
* | * All actor states, trigger matching, and transitions are managed by IPDL-generated code. Your C++ code need not manage these things. | ||
* | * All messages sent and received are checked against the protocol's state machine. ''If a message violates the state machine semantics defined in the IPDL code, the child process containing the child actor will be terminated with extreme prejudice, and all parent actors made invalid!'' It is up to the developer to make sure that this never happens. | ||
* Lots of syntactic sugar is possible for state machine definitions. Ping the Electrolysis team if you have a good proposal. | |||
== Checkpoint 2 == | == Checkpoint 2 == | ||