@@ -12,9 +12,9 @@ or `spawn` if it's more convenient:
1212
1313` Dagger.spawn(f, Dagger.Options(options), args...; kwargs...) `
1414
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,
1818such as in ` Dagger.@spawn f(Dagger.@spawn g()) ` , then, in this example, the
1919function ` f ` gets passed the results of executing ` g() ` , once that result is
2020available. 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).
2929
3030!!! note "Task / thread occupancy"
3131 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 ) ).
3333 The section [ Changing the thread occupancy] ( @ref ) shows a runnable example of how to achieve this.
3434
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+
3543## Simple example
3644
3745Let's see a very simple directed acyclic graph (or DAG) constructed with Dagger:
@@ -51,7 +59,7 @@ s = Dagger.@spawn combine(p, q, r)
5159@assert fetch (s) == 16
5260```
5361
54- The thunks ` p ` , ` q ` , ` r ` , and ` s ` have the following structure:
62+ The tasks ` p ` , ` q ` , ` r ` , and ` s ` have the following structure:
5563
5664![ graph] ( https://user-images.githubusercontent.com/25916/26920104-7b9b5fa4-4c55-11e7-97fb-fe5b9e73cae6.png )
5765
@@ -108,15 +116,16 @@ x::DTask
108116@assert fetch(x) == 3 # fetch the result of `@spawn`
109117```
110118
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 ) .
112121
113122## Options
114123
115124The [ ` Options ` ] (@ref Dagger.Options) struct in the second argument position is
116125optional; if provided, it is passed to the scheduler to control its
117126behavior. [ ` Options ` ] (@ref Dagger.Options) contains a ` NamedTuple ` of option
118127key-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 ) )
120129- ` meta::Bool ` -- Pass the input [ ` Chunk ` ] ( @ref ) objects themselves to ` f ` and
121130 not the value contained in them.
122131
@@ -127,19 +136,19 @@ There are also some extra options that can be passed, although they're considere
127136
128137## Errors
129138
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
133142determined 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
136145or not.
137146
138147This 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 ) )
140149` 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.
143152
144153## Cancellation
145154
198207```
199208
200209Alternatively, 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 `
202211object which references the result (see [ Chunks] ( @ref ) for more details):
203212
204213``` julia
@@ -215,16 +224,14 @@ Note that, as a legacy API, usage of the lazy API is generally discouraged for m
215224- Distinct schedulers don't share runtime metrics or learned parameters, thus causing the scheduler to act less intelligently
216225- Distinct schedulers can't share work or data directly
217226
218- ## Scheduler and Thunk options
227+ ## Task and Scheduler options
219228
220229While Dagger generally "just works", sometimes one needs to exert some more
221230fine-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.
228235
229236Scheduler options can be constructed and passed to ` collect() ` or ` compute() `
230237as the keyword argument ` options ` for lazy API usage:
@@ -238,7 +245,7 @@ compute(t; options=opts)
238245collect (t; options= opts)
239246```
240247
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:
242249
243250``` julia
244251# Execute on worker 1
@@ -251,8 +258,9 @@ delayed(+; single=1)(1, 2)
251258
252259## Changing the thread occupancy
253260
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).
256264The basic usage looks like this:
257265
258266``` julia
0 commit comments