task::spawn_local only available in feature = ["unstable"]

[FractalU]

The function 'task::spawn_local' is only behind the 'unstable' feature. However in the docs this function isn't marked as unstable. Is it actually unstable or not?

[FractalU]

Here the error message:

Compiling async_std_unstable v0.1.0 (C:\Users\Richard\Programming\Rust\async_std_unstable)
error[E0432]: unresolved import async_std::task::spawn_local
--> src\main.rs:1:5
|
1 | use async_std::task::spawn_local;
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^ no spawn_local in task

error: aborting due to previous error

For more information about this error, try rustc --explain E0432.
error: could not compile async_std_unstable.

To learn more, run the command again with --verbose.

[FractalU]

Here the Cargo.toml file:

[package]
............

[dependencies]
async-std = "1.6.1"

[FractalU]

Here the relevant portion of the docs:

block_on	Spawns a task and blocks the current thread on its result.
current	Returns a handle to the current task.
sleep	Sleeps for the specified amount of time.
spawn	Spawns a task.
spawn_blocking	unstable Spawns a blocking task.
spawn_local	Spawns a task onto the thread-local executor.
yield_now	Cooperatively gives up a timeslice to the task scheduler.

[zhaxzhax]

I have checked the source code. That's true, in the doc this function is not unstable. But actually you can only under unstable feature to use it. I have no idea whether to change the doc or the source code, could this function be stable? What's the standard for a function to be stable?

[dignifiedquire]

spawn_local is meant to be marked as unstable, as we are not fully certain it is the right interface and has the right properties. The docs are simply missing here.

I wonder if it would make sense to only enable spawn_local() inside block_on(), but not inside executor threads.

If executor threads run thread local executors, that means the event loop can't be moved onto a new thread, if need be. I can see us locking out of some amazing optimizations if we allow thread-local tasks on executor threads.

[yoshuawuyts]

@stjepang do you have any ideas what that API would look like? Would it panic if called inside executor threads?

Adding this restriction is certainly possible. I'd be curious to know more on how people are using this. The main use I have for spawn_local is for WASM where task spawning is !Send, which means this change wouldn't be a problem for me.

[piegamesde]

Until the exact API is figured out, the API doc should contain some more usage instructions:

• Do not use in synchronous context
• Only use in block_on

[kellpossible]

I'm currently having a problem where a task started in spawn_local (from main(), outside of any spawn or block_on)doesn't actually start/do anything. I was hoping to use it for something which is !Send.

[kellpossible]

If executor threads run thread local executors, that means the event loop can't be moved onto a new thread, if need be. I can see us locking out of some amazing optimizations if we allow thread-local tasks on executor threads.

Please forgive my lack of knowledge of the terminology, I'm new to async-std and async in general. Is block_on a "thread local executor"? How do you run a "thread local executor" inside the "executor thread"? Does calling spawn_local from within a spawn run a "thread local executor" within an "executor thread"? I'm having a little trouble understanding the situation fully. Does it relate back to this blog post, and if so how?

[kellpossible]

I'm currently having a problem where a task started in spawn_local (from main(), outside of any spawn or block_on)doesn't actually start/do anything. I was hoping to use it for something which is !Send.

I think I might figured out that my problem was that the thread which called the spawn_local blocks on some other regular blocking code (joining a thread), and doesn't block on a block_on call with some awaits inside to stoke an executor to run the task, and I'm not awaiting on the spawn_local join handle, so I'm guessing that means no executor was running?