Scheduler: Use the root task as a scheduler task

[kpamnany]

A Julia thread runs Julia's scheduler in the context of the switching task. If no task is found to switch to, the thread will sleep while holding onto the (possibly completed) task, preventing the task from being garbage collected. This recent Discourse post illustrates precisely this problem.

A solution to this would be for an idle Julia thread to switch to a "scheduler" task, thereby freeing the old task.

Other than thread 1, the root task that is created for every Julia-started (non-GC) thread essentially ends immediately -- we call jl_finish_task at the end of jl_threadfun.

This PR uses root tasks (on all but thread 1) as scheduler tasks. This solves the problem for all but thread 1. We could do the same for thread 1 also, but it would require special-casing as we cannot use thread 1's root task for this purpose.

[JeffBezanson]

We could do the same for thread 1 also, but it would require special-casing as we cannot use thread 1's root task for this purpose.

Why is this?

[gbaraldi]

Thread 1s root task actually does stuff like run the REPL/toplevel code. So it's a dead task

[kpamnany]

I considered creating a new task in julia_init and making that the root task, but the thread calling julia_init also needs to be wrapped in a task. Alternatively, we could add a sched_task to the TLS alongside root_task and use that uniformly on all threads instead. I chose the simplest option, but am open to any suggestions for improvement.

[vchuravy]

Could we make the root task on thread 1, do nothing but launch a task that does the work it used to do, and thus it becomes the scheduler task?

[kpamnany]

Could we make the root task on thread 1, do nothing but launch a task that does the work it used to do, and thus it becomes the scheduler task?

We can. It gets complicated though, because we have to return from julia_init, so we need the caller's stack, which is the standard process stack (i.e. larger than our typical task stack). Also, if we make the root task on thread 1 the scheduler task, then what's the task wrapping the julia_init caller? Do we root that somewhere?

Am I understanding your suggestion correctly?

[kpamnany]

@vtjnash suggested a couple of alternative ways to do this. Both have pros and cons, so I'd like to invite discussion.

With the first alternative, the scheduler uses a new field in ptls to instruct the task switching code (jl_switch) to not complete the task switch to the root task, but to get another task from the scheduler and switch to that instead.

Pros:

• Uniform behavior for all threads (as opposed to this PR, which excludes thread 1).

Cons:

• Complicated.
• Additional binding between the scheduler and the task switching code.

The second alternative uses a OncePerThread{Task} and not the root task, and moves the logic into Julia code.

Pros:

• Uniform behavior for all threads.
• Adding new code in Julia rather than C.

Cons:

• The task switch to the "scheduler" task happens almost immediately rather than after the thread sleep interval since that interval is handler in C. This introduces additional latency due to the additional task switch.

I don't much like the first alternative -- it's tricky, hard to understand/explain, and complicates the scheduler interface which will make it harder to switch schedulers.

I like the second alternative, but feel that the "early" switch to the scheduler task is problematic and this switch should happen only after the thread sleep interval. IMO the second alternative would be best once the thread sleep logic moves to Julia.

So I feel the current PR is still the right way to do this, but would like to hear other folks' opinions.

[kpamnany]

Closing this in favor of #57544:

• It is simpler.
• It is uniform across all threads (not excluding thread 1, like this PR).
• It is pure Julia -- no added C.