repeated threads loop hangs on windows

[JeffBezanson]

Calling this function on windows:

function f()
    nt = Threads.nthreads()
    for k in 1:5
        v = zeros(32 * nt)
        Threads.@threads for n in 1:nt
            for i in 1:100000000
                v[32 * n] += i
            end
        end
        @show k, v[32 .* (1:nt)]
    end
end

with JULIA_NUM_THREADS > 1 ends up hanging, using 100% of one CPU. It sometimes gets through some iterations of the outer loop first. Can anybody reproduce this? Works fine on linux.

[KristofferC]

Can repro on windows. On WSL it works fine.

Ctrl-C leads to

julia> f()
ERROR: InterruptException:
Stacktrace:
 [1] macro expansion at .\threadingconstructs.jl:75 [inlined]
 [2] f() at .\REPL[1]:5
 [3] top-level scope at REPL[2]:1
caused by [exception 1]
InterruptException:
Stacktrace:
 [1] process_events at .\libuv.jl:98 [inlined]
 [2] wait() at .\task.jl:593
 [3] wait(::Base.GenericCondition{Base.Threads.SpinLock}) at .\condition.jl:104
 [4] wait(::Task) at .\task.jl:191
 [5] macro expansion at .\threadingconstructs.jl:75 [inlined]
 [6] f() at .\REPL[1]:5
 [7] top-level scope at REPL[2]:1

[JeffBezanson]

Is it possible to attach a debugger and get the stack trace for each thread?

[JeffBezanson]

Did that, and I basically see thread 1 spinning or blocking while trying to wait on the thread loop tasks, even though all the tasks should have finished.

[JeffBezanson]

I also observe that sometimes when it appears to be hanging, simply attaching and detaching gdb makes it continue and make forward progress (i.e. print another line or two of output).

[JeffBezanson]

One theory I have is that this has to do with the delivery of signals from uv_async_send. It seems to be less predictable or work differently on windows.

[JeffBezanson]

Closed by #32109

[StefanKarpinski]

Should a new issue be opened to track fixing this in a better way?

[vtjnash]

The PR #32029 was also expected to fix this

[JeffBezanson]

I was hoping so, but I tried it and the problem was still there.