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
Spawns a Dagger `DTask` that will call `f(args...; kwargs...)`. This `DTask` is like a Julia `Task`, and has many similarities:
316
+
- The `DTask` can be `wait`'d on and `fetch`'d from to see its final result
317
+
- By default, the `DTask` will be automatically run on the first available compute resource
318
+
- If all dependencies are satisfied, the `DTask` will be run as soon as possible
319
+
- The `DTask` may be run in parallel with other `DTask`s, and the scheduler will automatically manage dependencies
320
+
- If a `DTask` throws an exception, it will be propagated to any calls to `fetch`, but not to calls to `wait`
321
+
322
+
However, the `DTask` also has many key differences from a `Task`:
323
+
- The `DTask` may run on any thread of any Julia process, and even on a remote machine, in your cluster (see `Distributed.addprocs`)
324
+
- The `DTask` might automatically utilize GPUs or other accelerators, if available
325
+
- If arguments to a `DTask` are also `DTask`s, then the scheduler will execute those arguments' `DTask`s first, before running the "downstream" task
326
+
- If an argument to a `DTask` `t2` is a `DTask` `t1`, then the *result* of `t1` (gotten via `fetch(t1)`) will be passed to `t2` (no need for `t2` to call `fetch`!)
327
+
- `DTask`s are generally expected to be defined "functionally", meaning that they should not mutate global state, mutate their arguments, or have side effects
328
+
- `DTask`s are function call-focused, meaning that `Dagger.@spawn` expects a single function call, and not a block of code
329
+
- All `DTask` arguments are expected to be safe to serialize and send to other Julia processes; if not, use the `scope` option or `Dagger.@mutable` to control execution location
330
+
331
+
Options to the `DTask` can be set before the call to `f` with key-value syntax, e.g.
332
+
`Dagger.@spawn myopt=2 do_something(1, 3.0)`, which would set the option
333
+
`myopt` to `2` for this task. Multiple options may be provided, which are
334
+
specified like `Dagger.@spawn myopt=2 otheropt=4 do_something(1, 3.0)`.
335
+
336
+
These options control a variety of properties of the resulting `DTask`:
337
+
- `scope`: The execution "scope" of the task, which determines where the task will run. By default, the task will run on the first available compute resource. If you have multiple compute resources, you can specify a scope to run the task on a specific resource. For example, `Dagger.@spawn scope=Dagger.scope(worker=2) do_something(1, 3.0)` would run `do_something(1, 3.0)` on worker 2.
338
+
- `meta`: If `true`, instead of the scheduler automatically fetching values from other tasks, the raw `Chunk` objects will be passed to `f`. Useful for doing manual fetching or manipulation of `Chunk` references. Non-`Chunk` arguments are still passed as-is.
339
+
340
+
Other options exist; see `Dagger.Sch.ThunkOptions` for the full list.
341
+
342
+
This macro is a semi-thin wrapper around `Dagger.spawn` - it creates a call to
343
+
`Dagger.spawn` on `f` with arguments `args` and keyword arguments `kwargs`, and
344
+
also passes along any options in an `Options` struct. For example,
345
+
`Dagger.@spawn myopt=2 do_something(1, 3.0)` would essentially become
0 commit comments