|
86 | 86 | |
87 | 87 | :report-chan - a core.async chan for reading.'ping' reponses |
88 | 88 | will show up here, as will any explicit ::flow/report outputs |
89 | | - from :transform/:introduce |
| 89 | + from :transform |
90 | 90 | |
91 | 91 | :error-chan - a core.async chan for reading. Any (and only) |
92 | 92 | exceptions thrown anywhere on any thread inside a flow will appear |
|
141 | 141 | "Given a map of functions (described below), returns a launcher that |
142 | 142 | creates a process compliant with the process protocol (see the |
143 | 143 | spi/ProcLauncher doc). The possible entries for process-impl-map |
144 | | - are :describe, :init, :transition, :transform and :introduce. This is |
| 144 | + are :describe, :init, :transition and :transform. This is |
145 | 145 | the core facility for defining the logic for processes via ordinary |
146 | 146 | functions. |
147 | 147 |
|
|
167 | 167 |
|
168 | 168 | :init - optional, (arg-map) -> initial-state |
169 | 169 | |
170 | | - init will be called once by the process to establish any |
171 | | - initial state. The arg-map will be a map of param->val, as supplied |
172 | | - in the flow def. init must be provided if 'describe' returns :params. |
| 170 | + init will be called once by the process to establish any initial |
| 171 | + state. The arg-map will be a map of param->val, as supplied in the |
| 172 | + flow def. init must be provided if 'describe' returns :params. |
| 173 | +
|
| 174 | + Optionally, a returned init state may contain the |
| 175 | + keys ::flow/in-ports and/or ::flow/out-ports. These should be maps |
| 176 | + of cid -> a core.async.channel. The cids must not conflict with the |
| 177 | + in/out ids. These channels will become part of the read/write set of |
| 178 | + the process, but are not otherwise visible/resolvable within the |
| 179 | + flow. Ports are a way to have data enter or exit the flow from |
| 180 | + outside. Use :transition to coordinate the lifecycle of these |
| 181 | + external channels. |
173 | 182 |
|
174 | 183 | :transition - optional, (state transition) -> state' |
175 | 184 |
|
|
181 | 190 | process will no longer be used following that. See the SPI for |
182 | 191 | details. state' will be the state supplied to subsequent calls. |
183 | 192 |
|
184 | | - Exactly one of either :transform or :introduce are required. |
185 | | -
|
186 | | - :transform - (state in-name msg) -> [state' output] |
| 193 | + :transform - required, (state in-name msg) -> [state' output] |
187 | 194 | where output is a map of outid->[msgs*] |
188 | 195 |
|
189 | 196 | The transform fn will be called every time a message arrives at any |
|
194 | 201 | may never be nil (per core.async channels). state' will be the state |
195 | 202 | supplied to subsequent calls. |
196 | 203 |
|
197 | | - :introduce - (state) -> [state' output] |
198 | | - where output is a map of outid->[msgs*], per :transform |
199 | | - |
200 | | - The introduce fn is used for sources - proc-impls that introduce new data |
201 | | - into the flow by doing I/O with something external to the flow and |
202 | | - feeding that data to its outputs. A proc-impl specifying :introduce may not |
203 | | - specify any :ins in its descriptor, as none but the ::flow/control channel |
204 | | - will be read. Instead, introduce will be called every time through the |
205 | | - process loop, and will presumably do blocking or paced I/O to get |
206 | | - new data to return via its outputs. If it does blocking I/O it |
207 | | - should do so with a timeout so it can regularly return to the |
208 | | - process loop which can then look for control messages - it's fine |
209 | | - for introduce to return with no output. Do not spin poll in the introduce |
210 | | - fn. |
211 | | -
|
212 | 204 | process accepts an option map with keys: |
213 | 205 | :workload - one of :mixed, :io or :compute |
214 | 206 | :compute-timeout-ms - if :workload is :compute, this timeout (default 5000 msec) |
|
218 | 210 | any :workload returned by the :describe fn of the process. If neither |
219 | 211 | are provded the default is :mixed. |
220 | 212 |
|
221 | | - The :compute workload is not allowed for proc impls that |
222 | | - provide :introduce (as I/O is presumed). |
223 | | -
|
224 | 213 | In the :workload context of :mixed or :io, this dictates the type of |
225 | 214 | thread in which the process loop will run, _including its calls to |
226 | | - transform/introduce_. |
| 215 | + transform_. |
227 | 216 |
|
228 | | - When :io is specified transform/introduce should not do extensive computation. |
| 217 | + When :io is specified, transform should not do extensive computation. |
229 | 218 |
|
230 | 219 | When :compute is specified (only allowed for :transform), each call |
231 | 220 | to transform will be run in a separate thread. The process loop will |
|
281 | 270 | and one output (named :in and :out), and no state." |
282 | 271 | [f] |
283 | 272 | (fn |
284 | | - ([] {:params {} |
285 | | - :ins {:in (str "the argument to " f)} |
| 273 | + ([] {:ins {:in (str "the argument to " f)} |
286 | 274 | :outs {:out (str "the return of " f)}}) |
287 | 275 | ([_] nil) |
288 | 276 | ([_ _ msg] [nil {:out (f msg)}]))) |
|
0 commit comments