|
81 | 81 | channel returned from start</pre></div></div><div class="public anchor" id="var-process"><h3>process</h3><div class="usage"><code>(process process-impl-map)</code><code>(process process-impl-map {:keys [workload timeout-ms], :or {timeout-ms 5000}, :as opts})</code></div><div class="doc"><pre class="plaintext">Given a map of functions (described below), returns a launcher that
|
82 | 82 | creates a process compliant with the process protocol (see the
|
83 | 83 | spi/ProcLauncher doc). The possible entries for process-impl-map
|
84 |
| -are :describe, :init, :transition, :transform and :introduce. This is |
| 84 | +are :describe, :init, :transition and :transform. This is |
85 | 85 | the core facility for defining the logic for processes via ordinary
|
86 | 86 | functions.
|
87 | 87 |
|
|
107 | 107 |
|
108 | 108 | :init - optional, (arg-map) -> initial-state
|
109 | 109 |
|
110 |
| -init will be called once by the process to establish any |
111 |
| -initial state. The arg-map will be a map of param->val, as supplied |
112 |
| -in the flow def. init must be provided if 'describe' returns :params. |
| 110 | +init will be called once by the process to establish any initial |
| 111 | +state. The arg-map will be a map of param->val, as supplied in the |
| 112 | +flow def. init must be provided if 'describe' returns :params. |
| 113 | + |
| 114 | +Optionally, a returned init state may contain the |
| 115 | +keys ::flow/in-ports and/or ::flow/out-ports. These should be maps |
| 116 | +of cid -> a core.async.channel. The cids must not conflict with the |
| 117 | +in/out ids. These channels will become part of the read/write set of |
| 118 | +the process, but are not otherwise visible/resolvable within the |
| 119 | +flow. Ports are a way to have data enter or exit the flow from |
| 120 | +outside. Use :transition to coordinate the lifecycle of these |
| 121 | +external channels. |
113 | 122 |
|
114 | 123 | :transition - optional, (state transition) -> state'
|
115 | 124 |
|
|
121 | 130 | process will no longer be used following that. See the SPI for
|
122 | 131 | details. state' will be the state supplied to subsequent calls.
|
123 | 132 |
|
124 |
| -Exactly one of either :transform or :introduce are required. |
125 |
| - |
126 |
| -:transform - (state in-name msg) -> [state' output] |
| 133 | +:transform - required, (state in-name msg) -> [state' output] |
127 | 134 | where output is a map of outid->[msgs*]
|
128 | 135 |
|
129 | 136 | The transform fn will be called every time a message arrives at any
|
|
134 | 141 | may never be nil (per core.async channels). state' will be the state
|
135 | 142 | supplied to subsequent calls.
|
136 | 143 |
|
137 |
| -:introduce - (state) -> [state' output] |
138 |
| -where output is a map of outid->[msgs*], per :transform |
139 |
| - |
140 |
| -The introduce fn is used for sources - proc-impls that introduce new data |
141 |
| -into the flow by doing I/O with something external to the flow and |
142 |
| -feeding that data to its outputs. A proc-impl specifying :introduce may not |
143 |
| -specify any :ins in its descriptor, as none but the ::flow/control channel |
144 |
| -will be read. Instead, introduce will be called every time through the |
145 |
| -process loop, and will presumably do blocking or paced I/O to get |
146 |
| -new data to return via its outputs. If it does blocking I/O it |
147 |
| -should do so with a timeout so it can regularly return to the |
148 |
| -process loop which can then look for control messages - it's fine |
149 |
| -for introduce to return with no output. Do not spin poll in the introduce |
150 |
| -fn. |
151 |
| - |
152 | 144 | process accepts an option map with keys:
|
153 | 145 | :workload - one of :mixed, :io or :compute
|
154 | 146 | :compute-timeout-ms - if :workload is :compute, this timeout (default 5000 msec)
|
|
158 | 150 | any :workload returned by the :describe fn of the process. If neither
|
159 | 151 | are provded the default is :mixed.
|
160 | 152 |
|
161 |
| -The :compute workload is not allowed for proc impls that |
162 |
| -provide :introduce (as I/O is presumed). |
163 |
| - |
164 | 153 | In the :workload context of :mixed or :io, this dictates the type of
|
165 | 154 | thread in which the process loop will run, _including its calls to
|
166 |
| -transform/introduce_. |
| 155 | +transform_. |
167 | 156 |
|
168 |
| -When :io is specified transform/introduce should not do extensive computation. |
| 157 | +When :io is specified, transform should not do extensive computation. |
169 | 158 |
|
170 | 159 | When :compute is specified (only allowed for :transform), each call
|
171 | 160 | to transform will be run in a separate thread. The process loop will
|
|
182 | 171 |
|
183 | 172 | :report-chan - a core.async chan for reading.'ping' reponses
|
184 | 173 | will show up here, as will any explicit ::flow/report outputs
|
185 |
| -from :transform/:introduce |
| 174 | +from :transform |
186 | 175 |
|
187 | 176 | :error-chan - a core.async chan for reading. Any (and only)
|
188 | 177 | exceptions thrown anywhere on any thread inside a flow will appear
|
|
0 commit comments