|
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