spawn_local should return a JoinHandle

[kaimast]

There seems to be no way to wait on running tasks or abort them. Could spawn_local return a JoinHandle, like tokio::spawn?

[Madoshakalaka]

Thanks for bringing this up. It's a valid gap in the current API.

The fire-and-forget design was intentional (see the comment in local_worker.rs and tokio-rs/tokio#4819), but the two reasons behind it are less compelling today than when the decision was made:

1. "Avoids the cost to acquire a JoinHandle" -- on native, tokio::task::spawn_local already allocates a JoinHandle internally that we discard. So we're paying the cost without the benefit.

2. "No meaningful JoinHandle until WASM supports unwinding" -- this blocks a tokio-compatible JoinHandle (one that captures panics via Result<T, JoinError>), but not a simpler handle. A JoinHandle<T> that supports .await for completion and .abort() for cancellation can be implemented on both platforms today using futures::future::Abortable + a oneshot channel, with no dependency on unwinding.

I'm open to adding this. The shape I have in mind:

• spawn_local and spawn_pinned return JoinHandle<T>, with Future<Output = T> replacing the current Future<Output = ()> bound
• .await on the handle yields Option<T> (None if the task was aborted)
• .abort() cancels the task
• No panic propagation (panics on WASM abort the program, same as today)
• A _detached variant preserves the current fire-and-forget behavior for callers that don't need the handle

This would be a breaking change (return type + output bound)

If you have thoughts on the Option<T> vs a dedicated error type for the await output, I'd like to hear them.

Also tagging @futursolo , who made the desicion to not return a handle.

[futursolo]

Avoids the cost to acquire a JoinHandle

This is a statement for spawn_pinned and not spawn_local.

No meaningful JoinHandle until WASM supports unwinding

My two cents about this is that we should probably see how the upstream crate progresses so we avoid breaking the implementation twice.
Being a fundamental library, publishing breaking changes frequently basically means we won't have any ecosystem around it.
(E.g.: Libraries referencing Tokise 0.2 BufStream are not compatible with libraries using Tokise 0.3 BufStream. If you bump the version 3 times a year, you won’t have libraries referencing Tokise BufStream publicly at all.)

See: wasm-bindgen/wasm-bindgen#5048

[Madoshakalaka]

Thanks for the advice. I see why it's wise to avoid breaking changes for Tokise now. I hope Edition 2024 of Tokise 0.3 will serve as a stable foundation for many patches to come.