Document assumptions on the iterators for the different `Threads.@threads` schedulers

[draftman9]

Julia Version: 1.10.5+0.x64.linux.gnu (installed by juliaup)
OS/Architecture: Linux x86_64, Ubuntu 22.04

The Threads.@threads macro does not seem to support iterating directly over a Channel, as it appears to require a collection that implements the length method. This is a common and intuitive pattern for parallel producer-consumer workflows, and its failure can be surprising.

Minimal Working Example (test.jl)

using Base.Threads

requests = Channel{Int}(3)
put!(requests, 1)
put!(requests, 2)
put!(requests, 3)
close(requests)

Threads.@threads for item in requests
    # Use a lock to prevent garbled output from multiple threads printing at once
    lock(print_lock) do
        println("Thread $(threadid()) took from Channel: $item")
    end
end

Actual Behavior (Error)

Running the code with julia -t 4 test.jl throws a TaskFailedException because the underlying tasks fail with a MethodError.

↪ julia -t 4 test.jl 
ERROR: LoadError: TaskFailedException

    nested task error: MethodError: no method matching length(::Channel{Int64})
    
    Closest candidates are:
      length(::Core.SimpleVector)
       @ Base essentials.jl:770
      length(::LibGit2.GitBlob)
       @ LibGit2 /media/Big/replaceC/.julia/juliaup/julia-1.10.5+0.x64.linux.gnu/share/julia/stdlib/v1.10/LibGit2/src/blob.jl:3
      length(::Core.Compiler.InstructionStream)
       @ Base show.jl:2777
      ...
    
    Stacktrace:
     [1] (::var"#59#threadsfor_fun#3"{var"#59#threadsfor_fun#1#4"{Channel{Int64}}})(tid::Int64; onethread::Bool)
       @ Main ./threadingconstructs.jl:184
     [2] (::var"#59#threadsfor_fun#3"{var"#59#threadsfor_fun#1#4"{Channel{Int64}}})(tid::Int64)
       @ Main ./threadingconstructs.jl:182
     [3] (::Base.Threads.var"#1#2"{var"#59#threadsfor_fun#3"{var"#59#threadsfor_fun#1#4"{Channel{Int64}}}, Int64})()
       @ Base.Threads ./threadingconstructs.jl:154

...and 3 more exceptions.

Stacktrace:
 [1] threading_run(fun::var"#59#threadsfor_fun#3"{var"#59#threadsfor_fun#1#4"{Channel{Int64}}}, static::Bool)
   @ Base.Threads ./threadingconstructs.jl:172
 [2] macro expansion
   @ ./threadingconstructs.jl:220 [inlined]
 [3] top-level scope
   @ /media/Big/folder-by-syncthing/something-fun-by-julia/parallel-dynamic-vs-static/test.jl:219
in expression starting at /media/Big/folder-by-syncthing/something-fun-by-julia/parallel-dynamic-vs-static/test.jl:9

[vchuravy]

The documentation could be better here, but the different schedulers assume different things from the iterator:

• :dynamic & :static assume length and getindex.
  • :dynamic:

    Each task processes contiguous regions of the iteration space.

  • :static:

    scheduler creates one task per thread and divides the iterations equally among them

• :greedy only assumes iterate

  each greedily working on the given iterated values as they are produced. As soon as one task finishes its work, it takes the next value from the iterator. Work done by any individual task is not necessarily on contiguous values from the iterator. The given iterator may produce values forever, only the iterator interface is required (no indexing).

See ??Threads.@threads

So Threads.@threads :greedy for item in requests should do the trick.

[Seelengrab]

Yes, the intention behind :greedy is precisely to support things like Channel that can't be indexed. It's a very naive implementation, no special care is taken for managing backpressure or internal batching for overall pipeline efficiency. In certain situations, there is definitely room for improvement, but it should be good enough for basic use cases.

[draftman9]

Yes :greedy is OK. Thank you both.