Deprecate Base.@async

[kpamnany]

Julia does need the ability to pin a task to a thread (in our current terminology: make it sticky). This currently happens implicitly for tasks created with Base.@async to support its semantics. To support those semantics, the parent task must also be made sticky. More precisely, if a newly created task S is sticky (which they are when created with Task() or @task), then whichever task calls schedule(S) will also be made sticky. A task that calls the AsyncCondition(callback) constructor (which spawns an @async task) will become sticky, as will a task that calls Timer(callback).

This sort of stickiness-infection ignores threadpool boundaries -- a task created on the default threadpool can end up being stuck to an interactive thread.

We can fix some of these (as we have previously), but we cannot fix them all, due to @async semantics.

Furthermore, such stickiness-infected tasks are never unstuck. There is this PR which attempts to unstick such tasks, but adds too much overhead.

We should introduce an explicit task pin/unpin interface (see #52108) and deprecate Base.@async so that all this implicit stickiness and associated cruft can be removed from the runtime.

[kpamnany]

We cannot actually remove Base.@async until Julia 2.0 of course, as it would be a breaking change. But deprecating it with a suggestion to:

• use pin/unpin if you want to stay on the same thread to call into a library, and
• use @spawn and a lock or channel to interact with another task if you want Base.@async semantics,

Should be possible.

[jam-khan]

Hi, I would like to work on this issue. I am a beginner to open-source. If I could get some resources, or similar PR that deprecates something, that would be great! Thanks a lot!

[nsajko]

Deemphasizing @async in the docs seems like it should come before trying to deprecate it, xref #50356.

[IanButterworth]

Renaming (deprecating) the Threads module to Tasks, which has been discussed, would help generalize the meaning via the form Tasks.@spawn.