Scheduler: do not always switch to the scheduler task

[kpamnany]

Only switch when the current task is done/failed. Also, ignore all exceptions in the scheduler task.

Context.

The downside is that when Julia is lightly loaded, Ctrl+C will often do nothing at all. However, Ctrl+C is delivered to an essentially random task anyway so I'm not sure if this is worse.

@Keno and @vtjnash: I think this is a simple fix that can be added to 1.12 instead of backing the scheduler task out altogether. Thoughts?

[gbaraldi]

I'm not sure if I like this. Specifically because the whole point of the waiter task is to not have a task hogging a thread and vice versa. This just adds some complexity but the bad case is still there.

[kpamnany]

I'm not sure if I like this. Specifically because the whole point of the waiter task is to not have a task hogging a thread and vice versa. This just adds some complexity but the bad case is still there.

I'm not sure I understand. The scheduler task addresses the problem that a dead task (and everything it references) cannot be GCed until there is some other task for the thread to run. This fix doesn't change that. If the current task is not dead, then it's fine to not switch to another task?

[gbaraldi]

Part of at least my idea for the waiter task, is to avoid the case where when we want to schedule a task that's waiting on a lock or something but it's stuck to a thread. This means we have to wakeup the thread adding complexity to the scheduler and making it have to worry about this case. I would like to have every task either be schedulable or currently running

[vtjnash]

This should still kill the application, as currently this would make julia unkillable with ^C, which isn't intended (there is also some logic in task_done_hook to move the exception to the correct Task, which this prevents)

[kpamnany]

I saw the logic in task_done_hook, and thought about replicating it here but wasn't sure that was the right thing to do.

If we allow an InterruptException to kill this task, and simply restart it from wait(), then how is that different from just ignoring it?

[vtjnash]

Suggested change

	return yieldto(sched_task)
	istaskdone(sched_task) && sched_task = reset(get_sched_task)
	return yieldto(sched_task)

(plus implement reset)

Or remove the OncePerThread{Task}, since it adds a lot of unnecessary complexity here, and just use @task wait() here instead?

[kpamnany]

Re: @task wait(), I feel that it would add avoidable latency. If there is a way to implement a reset, that would make it unnecessary, yes? But how would I implement reset?

[vtjnash]

@task nothing is quite a bit less overhead than the while loop has now, and just directly switches to the task_done_hook (which ends with wait()) that uses a fresh task. The only complication I foresee is needing to flag that task as being a scheduler task, so that we don't keep looping here. So better yet:

scheduler_task() = nothing
if ct.start !== scheduler_task
     yieldto(Task(scheduler_task))
end

[kpamnany]

I made this change. Not sure how to evaluate. Thoughts? Also, cc: @gbaraldi.