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
Copy file name to clipboardExpand all lines: docs/processing_model.md
+5-63Lines changed: 5 additions & 63 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -10,19 +10,8 @@ In the literature, It's expected that all state-machine events should execute on
10
10
11
11
The main point is: What should happen if the state machine triggers nested events while processing a parent event?
12
12
13
-
```{hint}
14
-
The importance of this decision depends on your state machine definition. Also the difference between RTC
15
-
and non-RTC processing models is more pronounced in a multi-threaded system than in a single-threaded system.
16
-
In other words, even if you run in {ref}`Non-RTC model`, only one external {ref}`event` will be
17
-
handled at a time and all internal events will run before the next external event is called,
18
-
so you only notice the difference if your state machine definition has nested event triggers while
19
-
processing these external events.
20
-
```
21
-
22
-
There are two distinct models for processing events in the library. The default is to run in
23
-
{ref}`RTC model` to be compliant with the specs, where the {ref}`event` is put on a
24
-
queue before processing. You can also configure your state machine to run in
25
-
{ref}`Non-RTC model`, where the {ref}`event` will be run immediately.
13
+
This library atheres to the {ref}`RTC model` to be compliant with the specs, where the {ref}`event` is put on a
14
+
queue before processing.
26
15
27
16
Consider this state machine:
28
17
@@ -60,13 +49,13 @@ Consider this state machine:
60
49
61
50
In a run-to-completion (RTC) processing model (**default**), the state machine executes each event to completion before processing the next event. This means that the state machine completes all the actions associated with an event before moving on to the next event. This guarantees that the system is always in a consistent state.
62
51
63
-
If the machine is in `rtc` mode, the event is put on a queue.
52
+
Internally, the events are put on a queue before processing.
64
53
65
54
```{note}
66
-
While processing the queue items, if others events are generated, they will be processed sequentially.
55
+
While processing the queue items, if others events are generated, they will be processed sequentially in FIFO order.
67
56
```
68
57
69
-
Running the above state machine will give these results on the RTC model:
58
+
Running the above state machine will give these results:
70
59
71
60
```py
72
61
>>> sm = ServerConnection()
@@ -89,50 +78,3 @@ after 'connection_succeed' from 'connecting' to 'connected'
89
78
Note that the events `connect` and `connection_succeed` are executed sequentially, and the `connect.after` runs on the expected order.
90
79
```
91
80
92
-
## Non-RTC model
93
-
94
-
```{deprecated} 2.3.2
95
-
`StateMachine.rtc` option is deprecated. We'll keep only the **run-to-completion** (RTC) model.
96
-
```
97
-
98
-
In contrast, in a non-RTC (synchronous) processing model, the state machine starts executing nested events
99
-
while processing a parent event. This means that when an event is triggered, the state machine
100
-
chains the processing when another event was triggered as a result of the first event.
101
-
102
-
```{warning}
103
-
This can lead to complex and unpredictable behavior in the system if your state-machine definition triggers **nested
104
-
events**.
105
-
```
106
-
107
-
If your state machine does not trigger nested events while processing a parent event,
108
-
and you plan to use the API in an _imperative programming style_, you can consider using the synchronous mode (non-RTC).
109
-
110
-
In this model, you can think of events as analogous to simple method calls.
111
-
112
-
```{note}
113
-
While processing the {ref}`event`, if others events are generated, they will also be processed immediately, so a **nested** behavior happens.
114
-
```
115
-
116
-
Running the above state machine will give these results on the non-RTC (synchronous) model:
117
-
118
-
```py
119
-
>>> sm = ServerConnection(rtc=False)
120
-
enter 'disconnected'from'' given '__initial__'
121
-
122
-
>>> sm.send("connect")
123
-
exit'disconnected' to 'connecting' given 'connect'
124
-
on 'connect'from'disconnected' to 'connecting'
125
-
enter 'connecting'from'disconnected' given 'connect'
126
-
exit'connecting' to 'connected' given 'connection_succeed'
127
-
on 'connection_succeed'from'connecting' to 'connected'
128
-
enter 'connected'from'connecting' given 'connection_succeed'
129
-
after 'connection_succeed'from'connecting' to 'connected'
130
-
after 'connect'from'disconnected' to 'connecting'
131
-
['on_transition', 'on_connect']
132
-
133
-
```
134
-
135
-
```{note}
136
-
Note that the events `connect` and `connection_succeed` are nested, and the `connect.after`
137
-
unexpectedly only runs after `connection_succeed.after`.
0 commit comments