Reading through https://github.com/JuliaLang/julia/pull/40715 I believe task migration across threads is primed for 1.7 release. Very much looking forward to this, but also have some concerns around the clarity in semantics of task scheduling.
@async launches a task that schedules on and sticks to the current thread. How will this look after the task migration change?
In my view there are two kinds of async-non-concurrent execution you want in the system. For interfacing with external libraries or directly with thread local store, you may need tasks that stick to the current thread. For application layer async code (e.g., to overlap IO) what you typically want is to guarantee non-simultaneous execution of a set of tasks in a group (e.g., with the parent task and its children), however you aren’t restricted from these migrating across threads. I can see a need for both in my own use cases, so either the API needs to be extended to support this distinction, or task migration needs to be prohibited if a task launches any nested sticky tasks.
I’m curious what the plans are and everyone else’s thoughts. On the same token, perhaps the task scheduling macro API could be simplified and cleaned up; for instance with a single macro taking a scheduling policy argument, rather than a macro per use case. Scheduling policies I can think of would be unrestricted, bind-to-current-thread, bind-to-launch-thread, bind-to-parent-thread.
Yes that first issue is one I posted, and the second spawned out of that discussion. Longer term a stronger API for more advanced control would be great.