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
When called, it creates an `EagerThunk` (also known as a "thunk" or "task")
12
-
object representing a call to function `f` with the arguments `args` and
15
+
When called, it creates an [`EagerThunk`](@ref) (also known as a "thunk" or
16
+
"task") object representing a call to function `f` with the arguments `args` and
13
17
keyword arguments `kwargs`. If it is called with other thunks as args/kwargs,
14
18
such as in `Dagger.@spawn f(Dagger.@spawn g())`, then, in this example, the
15
19
function `f` gets passed the results of executing `g()`, once that result is
@@ -18,21 +22,23 @@ waits on `g()` to complete before executing.
18
22
19
23
An important observation to make is that, for each argument to
20
24
`@spawn`/`spawn`, if the argument is the result of another `@spawn`/`spawn`
21
-
call (thus it's an `EagerThunk`), the argument will be computed first, and then
25
+
call (thus it's an [`EagerThunk`](@ref)), the argument will be computed first, and then
22
26
its result will be passed into the function receiving the argument. If the
23
-
argument is *not* an `EagerThunk` (instead, some other type of Julia object),
27
+
argument is *not* an [`EagerThunk`](@ref) (instead, some other type of Julia object),
24
28
it'll be passed as-is to the function `f` (with some exceptions).
25
29
26
30
## Options
27
31
28
-
The `Options` struct in the second argument position is optional; if provided,
29
-
it is passed to the scheduler to control its behavior. `Options` contains a
30
-
`NamedTuple` of option key-value pairs, which can be any of:
31
-
- Any field in `Dagger.Sch.ThunkOptions` (see [Scheduler and Thunk options](@ref))
32
-
-`meta::Bool` -- Pass the input `Chunk` objects themselves to `f` and not the value contained in them
32
+
The [`Options`](@ref Dagger.Options) struct in the second argument position is
33
+
optional; if provided, it is passed to the scheduler to control its
34
+
behavior. [`Options`](@ref Dagger.Options) contains a `NamedTuple` of option
35
+
key-value pairs, which can be any of:
36
+
- Any field in [`Sch.ThunkOptions`](@ref) (see [Scheduler and Thunk options](@ref))
37
+
-`meta::Bool` -- Pass the input [`Chunk`](@ref) objects themselves to `f` and
38
+
not the value contained in them.
33
39
34
40
There are also some extra optionss that can be passed, although they're considered advanced options to be used only by developers or library authors:
35
-
-`get_result::Bool` -- return the actual result to the scheduler instead of `Chunk` objects. Used when `f` explicitly constructs a Chunk or when return value is small (e.g. in case of reduce)
41
+
-`get_result::Bool` -- return the actual result to the scheduler instead of [`Chunk`](@ref) objects. Used when `f` explicitly constructs a [`Chunk`](@ref) or when return value is small (e.g. in case of reduce)
36
42
-`persist::Bool` -- the result of this Thunk should not be released after it becomes unused in the DAG
37
43
-`cache::Bool` -- cache the result of this Thunk such that if the thunk is evaluated again, one can just reuse the cached value. If it’s been removed from cache, recompute the value.
38
44
@@ -68,9 +74,9 @@ The final result (from `fetch(s)`) is the obvious consequence of the operation:
68
74
### Eager Execution
69
75
70
76
Dagger's `@spawn` macro works similarly to `@async` and `Threads.@spawn`: when
71
-
called, it wraps the function call specified by the user in an`EagerThunk`
72
-
object, and immediately places it onto a running scheduler, to be executed once
73
-
its dependencies are fulfilled.
77
+
called, it wraps the function call specified by the user in an
78
+
[`EagerThunk`](@ref)object, and immediately places it onto a running scheduler,
79
+
to be executed once its dependencies are fulfilled.
74
80
75
81
```julia
76
82
x =rand(400,400)
@@ -181,8 +187,8 @@ Note that, as a legacy API, usage of the lazy API is generally discouraged for m
181
187
While Dagger generally "just works", sometimes one needs to exert some more
182
188
fine-grained control over how the scheduler allocates work. There are two
183
189
parallel mechanisms to achieve this: Scheduler options (from
184
-
`Dagger.Sch.SchedulerOptions`) and Thunk options (from
185
-
`Dagger.Sch.ThunkOptions`). These two options structs contain many shared
190
+
[`Sch.SchedulerOptions`](@ref)) and Thunk options (from
191
+
[`Sch.ThunkOptions`](@ref)). These two options structs contain many shared
186
192
options, with the difference being that Scheduler options operate
187
193
globally across an entire DAG, and Thunk options operate on a thunk-by-thunk
0 commit comments