Recommend @spawn over @async

[tkf]

Since arbitrary functions can use @async as an implementation detail, there's currently almost no way to protect against accidentally disabling migratability of a task. Unless we implement something like #41393 to mitigate this, I suggest recommending @spawn over @async always. I think this might be what we want to do eventually anyway to push the ecosystem to improve parallelism and concurrency support.

[Seelengrab]

Would it be possible to allow @async tasks to migrate as well instead? The combination of @async with @sync seems very useful to me - having to reimplement that manually with @spawn sounds cumbersome..

[jpsamaroo]

Would it be possible to allow @async tasks to migrate as well instead?

As I understand it, the current semantics of @async are strict such that we can't do this. There is code that uses @async under the expectation that the thread will not change during the task's lifetime.

[vtjnash]

We may get migration in the future at some point, but we haven't worked out the design details. They are permitted to change the underlying thread, but must arrange to ensure that no other disallowed @async block is run in parallel.

[vtjnash]

Seems reasonable to me

[tkf]

We can wait for more feedbacks but it's also very easy to just revert this. So, I think it's OK to merge this for now so that there's a larger chance that more people look at it before the actual release.