Merge pull request #518 from JuliaParallel/jps/dtask

Rename EagerThunk to DTask

Author: jpsamaroo

docs/src/api-dagger/functions.md

@@ -11,8 +11,6 @@ Pages = ["functions.md"]
 ```@docs
 @spawn
 spawn
-delayed
-@par
 ```
 
 ## Task Options Functions/Macros
@@ -38,16 +36,6 @@ scope
 constrain
 ```
 
-## Lazy Task Functions
-```@docs
-domain
-compute
-dependents
-noffspring
-order
-treereduce
-```
-
 ## Processor Functions
 ```@docs
 execute!

docs/src/api-dagger/types.md

@@ -10,7 +10,7 @@ Pages = ["types.md"]
 ## Task Types
 ```@docs
 Thunk
-EagerThunk
+DTask
 ```
 
 ## Task Options Types

docs/src/darray.md

@@ -353,8 +353,8 @@ Now, `DZ` will contain the result of computing `(DX .+ DX) .* 3`.
 ```
 julia> Dagger.chunks(DZ)
 2×2 Matrix{Any}:
- EagerThunk (finished)  EagerThunk (finished)
- EagerThunk (finished)  EagerThunk (finished)
+ DTask (finished)  DTask (finished)
+ DTask (finished)  DTask (finished)
 
 julia> Dagger.chunks(fetch(DZ))
 2×2 Matrix{Union{Thunk, Dagger.Chunk}}:
@@ -363,7 +363,7 @@ julia> Dagger.chunks(fetch(DZ))
 ```
 
 Here we can see the `DArray`'s internal representation of the partitions, which
-are stored as either `EagerThunk` objects (representing an ongoing or completed
+are stored as either `DTask` objects (representing an ongoing or completed
 computation) or `Chunk` objects (which reference data which exist locally or on
 other Julia workers). Of course, one doesn't typically need to worry about
 these internal details unless implementing low-level operations on `DArray`s.

docs/src/task-queues.md

@@ -14,7 +14,7 @@ queues".
 A task queue in Dagger is an object that can be configured to accept unlaunched
 tasks from `@spawn`/`spawn` and either modify them or delay their launching
 arbitrarily. By default, Dagger tasks are enqueued through the
-`EagerTaskQueue`, which submits tasks directly into the scheduler before
+`DefaultTaskQueue`, which submits tasks directly into the scheduler before
 `@spawn`/`spawn` returns. However, Dagger also has an `InOrderTaskQueue`, which
 ensures that tasks enqueued through it execute sequentially with respect to
 each other. This queue can be allocated with `Dagger.spawn_sequential`:

docs/src/task-spawning.md

@@ -12,7 +12,7 @@ or `spawn` if it's more convenient:
 
 `Dagger.spawn(f, Dagger.Options(options), args...; kwargs...)`
 
-When called, it creates an [`EagerThunk`](@ref) (also known as a "thunk" or
+When called, it creates an [`DTask`](@ref) (also known as a "thunk" or
 "task") object representing a call to function `f` with the arguments `args` and
 keyword arguments `kwargs`. If it is called with other thunks as args/kwargs,
 such as in `Dagger.@spawn f(Dagger.@spawn g())`, then, in this example, the
@@ -22,9 +22,9 @@ waits on `g()` to complete before executing.
 
 An important observation to make is that, for each argument to
 `@spawn`/`spawn`, if the argument is the result of another `@spawn`/`spawn`
-call (thus it's an [`EagerThunk`](@ref)), the argument will be computed first, and then
+call (thus it's an [`DTask`](@ref)), the argument will be computed first, and then
 its result will be passed into the function receiving the argument. If the
-argument is *not* an [`EagerThunk`](@ref) (instead, some other type of Julia object),
+argument is *not* an [`DTask`](@ref) (instead, some other type of Julia object),
 it'll be passed as-is to the function `f` (with some exceptions).
 
 ## Options
@@ -75,7 +75,7 @@ The final result (from `fetch(s)`) is the obvious consequence of the operation:
 
 Dagger's `@spawn` macro works similarly to `@async` and `Threads.@spawn`: when
 called, it wraps the function call specified by the user in an
-[`EagerThunk`](@ref) object, and immediately places it onto a running scheduler,
+[`DTask`](@ref) object, and immediately places it onto a running scheduler,
 to be executed once its dependencies are fulfilled.
 
 ```julia
@@ -114,7 +114,7 @@ One can also safely call `@spawn` from another worker (not ID 1), and it will be
 
 ```
 x = fetch(Distributed.@spawnat 2 Dagger.@spawn 1+2) # fetches the result of `@spawnat`
-x::EagerThunk
+x::DTask
 @assert fetch(x) == 3 # fetch the result of `@spawn`
 ```
 

docs/src/use-cases/parallel-nested-loops.md

@@ -72,12 +72,12 @@ end
 
 In this code we have job interdependence. Firstly, we are calculating the
 standard deviation `σ` and than we are using that value in the function `f`.
-Since `Dagger.@spawn` yields an `EagerThunk` rather than actual values, we need
+Since `Dagger.@spawn` yields an `DTask` rather than actual values, we need
 to use the `fetch` function to obtain those values. In this example, the value
 fetching is perfomed once all computations are completed (note that `@sync`
 preceding the loop forces the loop to wait for all jobs to complete). Also,
 note that contrary to the previous example, we do not need to implement locking
-as we are just pushing the `EagerThunk` results of `Dagger.@spawn` serially
+as we are just pushing the `DTask` results of `Dagger.@spawn` serially
 into the DataFrame (which is fast since `Dagger.@spawn` doesn't block).
 
 The above use case scenario has been tested by running `julia -t 8` (or with

ext/GraphVizExt.jl

@@ -7,7 +7,7 @@ else
 end
 
 import Dagger
-import Dagger: EagerThunk, Chunk, Processor
+import Dagger: DTask, Chunk, Processor
 import Dagger.TimespanLogging: Timespan
 import Graphs: SimpleDiGraph, add_edge!, add_vertex!, inneighbors, outneighbors, vertices, is_directed, edges, nv, src, dst
 

ext/PlotsExt.jl

@@ -9,7 +9,7 @@ else
 end
 
 import Dagger
-import Dagger: EagerThunk, Chunk, Processor
+import Dagger: DTask, Chunk, Processor
 import Dagger.TimespanLogging: Timespan
 
 function logs_to_df(logs::Dict)

src/Dagger.jl

@@ -45,7 +45,7 @@ include("utils/processors.jl")
 include("task-tls.jl")
 include("scopes.jl")
 include("utils/scopes.jl")
-include("eager_thunk.jl")
+include("dtask.jl")
 include("queue.jl")
 include("thunk.jl")
 include("submission.jl")

src/array/matrix.jl

@@ -66,7 +66,7 @@ function (+)(a::ArrayDomain, b::ArrayDomain)
 end
 
 struct BinaryComputeOp{F} end
-BinaryComputeOp{F}(x::Union{Chunk,EagerThunk}, y::Union{Chunk,EagerThunk}) where F = @spawn F(x, y)
+BinaryComputeOp{F}(x::Union{Chunk,DTask}, y::Union{Chunk,DTask}) where F = @spawn F(x, y)
 BinaryComputeOp{F}(x, y) where F = F(x, y)
 
 const AddComputeOp = BinaryComputeOp{+}