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: site/developer.md
+23-16Lines changed: 23 additions & 16 deletions
Original file line number
Diff line number
Diff line change
@@ -189,24 +189,31 @@ Each `Step` has a reference to the next `Step` in the processing flow; however,
189
189
In this sample, the caller creates an `Engine`, `Fiber`, linked set of `Step` instances, and `Packet`. The `Fiber` is then started. The `Engine` would typically be a singleton, since it's backed by a `ScheduledExecutorService`. The `Packet` would also typically be pre-loaded with values that the `Steps` would use in their `apply()` methods.
// Fiber processing was terminated with an exception
213
+
}
214
+
});
215
+
}
216
+
}
210
217
```
211
218
212
219
`Steps` must not invoke sleep or blocking calls from within `apply()`. This prevents the worker threads from serving other `Fibers`. Instead, use asynchronous calls and the `Fiber` suspend/resume pattern. `Step` provides a method, `doDelay()`, which creates a `NextAction` to drive `Fiber` suspend/resume that is a better option than sleep precisely because the worker thread can serve other `Fibers` during the delay. For asynchronous IO or similar patterns, suspend the `Fiber`. In the callback as the `Fiber` suspends, initiate the asynchronous call. Finally, when the call completes, resume the `Fiber`. The suspend/resume functionality handles the case where resumed before the suspending callback completes.
@@ -232,7 +239,7 @@ In this sample, the step uses asynchronous file IO and the suspend/resume `Fiber
0 commit comments