Feature request: prevent spawning to thread 1

[tro3]

Currently the scheduler through the Threads.@spawn macro will assign to random thread #'s, including the primary thread. There may be times where there is a "traffic cop" activity on Thread 1 that can be impacted if a heavy-computational (in essence, blocking) task is put onto that thread. It would be nice if there was a way to cordon off Thread 1 from spawning in those cases.

[tro3]

Alternately, of course, the equivalent of @spawnat would allow the same, but I don’t know (doubt, actually) how feasible that is.

[JeffBezanson]

Mostly a duplicate of #16350. We could add a thread reserved for latency-bound tasks.

[tro3]

Agreed that this issue and #34240 are the same. #16350 is highly-related but a little different, in that a single thread was being used by both a mostly-blocking task and the REPL. (If the yield were not there, I suspect it would have locked completely.) So that one just about whether the REPL gets its own thread.

I can close this one out if you want to just track the other - your guys' call.

[tknopp]

Also discussed here (for crossref): https://discourse.julialang.org/t/threading-1-3-success-story/27111/10

[quinnj]

I'll just comment that I've had a desire for something like this as well; particularly in the context of running a microservice/kernel, you want to keep a "heartbeat" thread always ready to respond/beat, while being able to spawn threaded-tasks elsewhere w/o worrying about completely saturating resources to the point that the heartbeat can't respond.

What's the path forward here? I saw that @JeffBezanson suggested potentially having a @spawn background ex macro form that would only spawn tasks on non-main threads. Would that require some functionality on the C-side? Do @JeffBezanson / @vtjnash think it'd be worth me trying to take a stab at this, or would it be pretty hairy? I'm eager to see this, so happy to jump in and help any way I can.

[tro3]

Is this as simple as...

task.jl:542

       tid = 0
        if ccall(:jl_enqueue_task, Cint, (Any,), t) != 0
            # if multiq is full, give to a random thread (TODO fix)
+           if t.background  # Perhaps nontrivial like this due to Core.Task mod, but you get the idea
+               tid = mod(time_ns() % Int, Threads.nthreads()-1) + 2
+           else
                tid = mod(time_ns() % Int, Threads.nthreads()) + 1
+           end
            ccall(:jl_set_task_tid, Cvoid, (Any, Cint), t, tid-1)
            push!(Workqueues[tid], t)
        end

? I'd be happy to do it and test, but I don't have the prereqs to build Julia. Is there a simple way to toggle the Base reference? (Seems like I read that at some point)

[tro3]

Of course, you’d need an @spawnbg or somesuch that sets the background bit before launch. I’ll see if I can get a Julia build running and PR it. (If someone more prepped wants to take it, be my guest :-) )

[tknopp]

What would that implementation do, if Julia is started with a single thread? IMHO, it needs some dynamic thread creation to be useful. I.e. start Julia with a single thread and increase the pool once @spawn is called.

[tro3]

Oh, totally agreed. The above code block is in the multi-threaded branch of the scheduler anyways - no change to single-thread. If it is a truly single thread situation with no ability to grow the thread count, then a non-yielding computational thread will block things and there isn't much to be done. Building a growable thread pool is a good idea, but I think will require a lot of stakeholder input before implementation. In my mind, the above would be more short-term, aimed at solving the frozen-GUI/REPL/Thread1-thing problem until the higher-level long term solution shows up.

[quinnj]

I think initially, something like @spawn background expr should just throw an error if there's only a single thread. It's simple and straightforward and a lot easier (I assume) than trying to support dynamically added runtime threads. We could perhaps also support allowing @spawn background expr to run the task in the main thread if desired. That could be useful in certain microservice workflows where you want to scale from 1 cpu all the way up to N+ cores.

[tknopp]

Yes, a step in-between is absolutely a good thing. Would prefer throwing an error instead of getting stuck. Would be great getting something in shape for 1.4.

[tro3]

No dice on the fix above - that "multiq full" branch never gets hit on my machine. (PC, 8 threads). So the thread assignment is being handled at the C level. If I try to use the jl_set_task_tid in the scheduler to manually assign the id, the machine locks up. I'll dig into the C side later tonight, but I won't be able to test - at best to find the proper way to change an id before launch.