@@ -12,9 +12,9 @@ or `spawn` if it's more convenient:
12
12
13
13
` Dagger.spawn(f, Dagger.Options(options), args...; kwargs...) `
14
14
15
- When called, it creates an [ ` DTask ` ] ( @ref ) (also known as a "thunk " or
16
- "task ") object representing a call to function ` f ` with the arguments ` args ` and
17
- keyword arguments ` kwargs ` . If it is called with other thunks as args/kwargs,
15
+ When called, it creates an [ ` DTask ` ] ( @ref ) (also known as a "task " or
16
+ "thunk ") object representing a call to function ` f ` with the arguments ` args ` and
17
+ keyword arguments ` kwargs ` . If it is called with other tasks as args/kwargs,
18
18
such as in ` Dagger.@spawn f(Dagger.@spawn g()) ` , then, in this example, the
19
19
function ` f ` gets passed the results of executing ` g() ` , once that result is
20
20
available. If ` g() ` isn't yet finished executing, then the execution of ` f `
@@ -29,9 +29,17 @@ it'll be passed as-is to the function `f` (with some exceptions).
29
29
30
30
!!! note "Task / thread occupancy"
31
31
By default, ` Dagger ` assumes that tasks saturate the thread they are running on and does not try to schedule other tasks on the thread.
32
- This default can be controlled by specifying [ ` Sch.ThunkOptions ` ] ( @ref ) (more details can be found under [ Scheduler and Thunk options] ( @ref ) ).
32
+ This default can be controlled by specifying [ ` Options ` ] ( @ref ) (more details can be found under [ Task and Scheduler options] ( @ref ) ).
33
33
The section [ Changing the thread occupancy] ( @ref ) shows a runnable example of how to achieve this.
34
34
35
+ ## Options
36
+
37
+ The [ ` Options ` ] (@ref Dagger.Options) struct in the second argument position is
38
+ optional; if provided, it is passed to the scheduler to control its
39
+ behavior. [ ` Options ` ] (@ref Dagger.Options) contains option
40
+ key-value pairs, which can be any field in [ ` Options ` ] ( @ref )
41
+ (see [ Task and Scheduler options] ( @ref ) ).
42
+
35
43
## Simple example
36
44
37
45
Let's see a very simple directed acyclic graph (or DAG) constructed with Dagger:
@@ -51,7 +59,7 @@ s = Dagger.@spawn combine(p, q, r)
51
59
@assert fetch (s) == 16
52
60
```
53
61
54
- The thunks ` p ` , ` q ` , ` r ` , and ` s ` have the following structure:
62
+ The tasks ` p ` , ` q ` , ` r ` , and ` s ` have the following structure:
55
63
56
64
![ graph] ( https://user-images.githubusercontent.com/25916/26920104-7b9b5fa4-4c55-11e7-97fb-fe5b9e73cae6.png )
57
65
@@ -108,15 +116,16 @@ x::DTask
108
116
@assert fetch(x) == 3 # fetch the result of `@spawn`
109
117
```
110
118
111
- This is useful for nested execution, where an ` @spawn ` 'd thunk calls ` @spawn ` . This is detailed further in [ Dynamic Scheduler Control] ( @ref ) .
119
+ This is useful for nested execution, where an ` @spawn ` 'd task calls ` @spawn ` .
120
+ This is detailed further in [ Dynamic Scheduler Control] ( @ref ) .
112
121
113
122
## Options
114
123
115
124
The [ ` Options ` ] (@ref Dagger.Options) struct in the second argument position is
116
125
optional; if provided, it is passed to the scheduler to control its
117
126
behavior. [ ` Options ` ] (@ref Dagger.Options) contains a ` NamedTuple ` of option
118
127
key-value pairs, which can be any of:
119
- - Any field in [ ` Sch.ThunkOptions ` ] ( @ref ) (see [ Scheduler and Thunk options] ( @ref ) )
128
+ - Any field in [ ` Options ` ] ( @ref ) (see [ Task and Scheduler options] ( @ref ) )
120
129
- ` meta::Bool ` -- Pass the input [ ` Chunk ` ] ( @ref ) objects themselves to ` f ` and
121
130
not the value contained in them.
122
131
@@ -127,19 +136,19 @@ There are also some extra options that can be passed, although they're considere
127
136
128
137
## Errors
129
138
130
- If a thunk errors while running under the eager scheduler, it will be marked as
131
- having failed, all dependent (downstream) thunks will be marked as failed, and
132
- any future thunks that use a failed thunk as input will fail. Failure can be
139
+ If a task errors while running under the eager scheduler, it will be marked as
140
+ having failed, all dependent (downstream) tasks will be marked as failed, and
141
+ any future tasks that use a failed task as input will fail. Failure can be
133
142
determined with ` fetch ` , which will re-throw the error that the
134
- originally-failing thunk threw. ` wait ` and ` isready ` will * not* check whether a
135
- thunk or its upstream failed; they only check if the thunk has completed, error
143
+ originally-failing task threw. ` wait ` and ` isready ` will * not* check whether a
144
+ task or its upstream failed; they only check if the task has completed, error
136
145
or not.
137
146
138
147
This failure behavior is not the default for lazy scheduling ([ Lazy API] ( @ref ) ),
139
- but can be enabled by setting the scheduler/thunk option ([ Scheduler and Thunk options] ( @ref ) )
148
+ but can be enabled by setting the scheduler/task option ([ Task and Scheduler options] ( @ref ) )
140
149
` allow_error ` to ` true ` . However, this option isn't terribly useful for
141
- non-dynamic usecases, since any thunk failure will propagate down to the output
142
- thunk regardless of where it occurs.
150
+ non-dynamic usecases, since any task failure will propagate down to the output
151
+ task regardless of where it occurs.
143
152
144
153
## Cancellation
145
154
198
207
```
199
208
200
209
Alternatively, if you want to compute but not fetch the result of a lazy
201
- operation, you can call ` compute ` on the thunk . This will return a ` Chunk `
210
+ operation, you can call ` compute ` on the task . This will return a ` Chunk `
202
211
object which references the result (see [ Chunks] ( @ref ) for more details):
203
212
204
213
``` julia
@@ -215,16 +224,14 @@ Note that, as a legacy API, usage of the lazy API is generally discouraged for m
215
224
- Distinct schedulers don't share runtime metrics or learned parameters, thus causing the scheduler to act less intelligently
216
225
- Distinct schedulers can't share work or data directly
217
226
218
- ## Scheduler and Thunk options
227
+ ## Task and Scheduler options
219
228
220
229
While Dagger generally "just works", sometimes one needs to exert some more
221
230
fine-grained control over how the scheduler allocates work. There are two
222
- parallel mechanisms to achieve this: Scheduler options (from
223
- [ ` Sch.SchedulerOptions ` ] ( @ref ) ) and Thunk options (from
224
- [ ` Sch.ThunkOptions ` ] ( @ref ) ). These two options structs contain many shared
225
- options, with the difference being that Scheduler options operate
226
- globally across an entire DAG, and Thunk options operate on a thunk-by-thunk
227
- basis.
231
+ parallel mechanisms to achieve this: Task options (from [ ` Options ` ] ( @ref ) ) and
232
+ Scheduler options (from [ ` Sch.SchedulerOptions ` ] ( @ref ) ). Scheduler
233
+ options operate globally across an entire DAG, and Task options operate on a
234
+ task-by-task basis.
228
235
229
236
Scheduler options can be constructed and passed to ` collect() ` or ` compute() `
230
237
as the keyword argument ` options ` for lazy API usage:
@@ -238,7 +245,7 @@ compute(t; options=opts)
238
245
collect (t; options= opts)
239
246
```
240
247
241
- Thunk options can be passed to ` @spawn/spawn ` , ` @par ` , and ` delayed ` similarly:
248
+ Task options can be passed to ` @spawn/spawn ` , ` @par ` , and ` delayed ` similarly:
242
249
243
250
``` julia
244
251
# Execute on worker 1
@@ -251,8 +258,9 @@ delayed(+; single=1)(1, 2)
251
258
252
259
## Changing the thread occupancy
253
260
254
- One of the supported [ ` Sch.ThunkOptions ` ] ( @ref ) is the ` occupancy ` keyword.
255
- This keyword can be used to communicate that a task is not expected to fully saturate a CPU core (e.g. due to being IO-bound).
261
+ One of the supported [ ` Options ` ] ( @ref ) is the ` occupancy ` keyword.
262
+ This keyword can be used to communicate that a task is not expected to fully
263
+ saturate a CPU core (e.g. due to being IO-bound).
256
264
The basic usage looks like this:
257
265
258
266
``` julia
0 commit comments