Add a LocalRuntime for replacing Runtime+LocalSet

[Darksonn]

Currently, to spawn !Send tasks on Tokio you must use a combination of a current-thread runtime and LocalSet to make that work. However, tasks on a LocalSet are separate from the rest of the runtime in an uncomfortable way. For example:

• Tasks on the LocalSet can tokio::spawn to get onto the runtime, but once you're on the runtime, you can no longer spawn_local to get back into the LocalSet.
• From the runtime's perspective, all of the tasks in the LocalSet behave like a single task using FuturesUnordered, so various runtime options such as event_interval behave in a very surprising way by counting many tasks at once.
• After discussions with Deno, the LocalSet has been shown to involve considerable performance overhead compared to unsafely spawning the !Send tasks onto a current-thread runtime.

For the above reasons, I propose introducing a new type called LocalRuntime which behaves exactly like a current-thread Runtime with the following exceptions:

• The LocalRuntime type is !Send to enable spawning !Send tasks directly onto the runtime.
• From within a LocalRuntime, the tokio::spawn and spawn_local functions have identical behavior.
• Tasks spawned using spawn_local are scheduled in the same way as normal tokio::spawn tasks.

Since Runtime and LocalSet share a fair amount of their internals, the implementation of current-thread should not require changes to support this.

[Noah-Kennedy]

I am strongly in favor of this proposal, and would be happy to take some time and write a PR to add this to tokio_unstable.

[Noah-Kennedy]

I've opened a PR to add this as an unstable API: https://github.com/tokio-rs/tokio/pull/6808

[carllerche]

Generally, I agree with the reasoning for adding LocalSet. We would need to think about how to position this with the current thread runtime. Both LocalRuntime and CurrentThreadRuntime have a lot of overlap. So, how to pick each one would need to be clear.

[Noah-Kennedy]

Generally, I agree with the reasoning for adding LocalSet. We would need to think about how to position this with the current thread runtime. Both LocalRuntime and CurrentThreadRuntime have a lot of overlap. So, how to pick each one would need to be clear.

I think the decision tree here comes down to several things:

• do you want to be able to seamlessly switch between multi_thread and current_thread (e.g via a config file entry in your service)
• do you want to move runtimes between threads (not as dumb as it sounds)
• do you actually care about spawn_local