Skip to content

Re-export task::spawn and task::spawn_blocking at top-level #1018

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
wants to merge 2 commits into from
Closed
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
3 changes: 3 additions & 0 deletions CHANGELOG.md
Original file line number Diff line number Diff line change
Expand Up @@ -8,6 +8,9 @@ and this project adheres to [Semantic Versioning](https://book.async.rs/overview
# [Unreleased]

## Added

- `std::task_spawn_blocking` is now stabilized. We consider it a fundamental API for bridging between blocking code and async code, and we widely use it within async-std's own implementation.

## Removed
## Changed

Expand Down
5 changes: 5 additions & 0 deletions src/lib.rs
Original file line number Diff line number Diff line change
Expand Up @@ -318,6 +318,11 @@ cfg_default! {
pub mod net;
#[cfg(not(target_os = "unknown"))]
pub(crate) mod rt;

#[cfg(not(target_os = "unknown"))]
pub use crate::task::spawn;
#[cfg(not(target_os = "unknown"))]
pub use crate::task::spawn_blocking;
Comment on lines +321 to +325
Copy link
Contributor

@yoshuawuyts yoshuawuyts Jun 2, 2022

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

A goal we had when designing async-std was to create a module hierarchy which resembled the hierarchy of the stdlib - but expanding on it with async-only capabilities in certain locations. This was with the expectation that one day we might add these APIs into the stdlib itself. And at least my hope is that we may eventually enable a diff like this:

- use async_std::task::spawn;
+ use std::task::spawn;

You're probably in a better position to answer this, but I kind of assumed that in the stdlib we would likely want to scope the spawn family of functions to submodules, and likely not expose them directly from std's root? Meaning that even if we create an async_std::spawn, we'd unlikely ever have a std::spawn?

Alternatives

I do think you're touching on an important insight here though: spawning tasks is a common operation, and making that convenient to perform seems important. I've recently been experimenting with making spawn a method on Future. This solves the same problem by not requiring any imports at all:

use tasky::prelude::*;
 
async_std::task::block_on(async {
    let res = async { "nori is a horse" }
        .spawn()               // <- `FutureExt::spawn`
        .name("meow".into())
        .await;
    assert_eq!(res, "nori is a horse");
})

Open questions
I've been contemplating whether we could add this to async-std as part of FutureExt, possibly even deprecating task::spawn as part of it. Though there are still a few open questions with this:

  1. The path for inclusion in the stdlib seems less clear. The base trait lives in core::future::Future, but this extension may only be possible on std? Perhaps there is something with contexts we could provide, or perhaps the unification of core and std would help? But I'm not sure what the right path for the stdlib here would be.
  2. The tasky prototype of this idea has both spawn and spawn_local variants of this method. This is probably worth its own blog post, but spawn_local doesn't appear to be the right abstraction. Instead we need to find a way to define a spawn method with "the captured values from the scope can be sent to another thread, but once the future is constructed it will no longer move between threads". Much like the thread::spawn API works. I'm not sure yet how to do this, as it seems like it needs to be implemented at the async-task layer.
  3. I'm not sure what to do about spawn_blocking. It doesn't really make sense to define it as FutureExt::spawn_blocking since it's only intended to be used for non-future workloads. Having a T::spawn_blocking feels wrong too. How common is it to use this method? What is the right way to expose this functionality?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You're right, we're unlikely to ever have a std::spawn, so we shouldn't make this change.

In theory, we could make spawn_blocking take a future, since it may want to run a mix of sync and async work.

But whether we do that or not, I'm not sure we want to have spawn as a method on futures.

}

cfg_unstable! {
Expand Down
4 changes: 0 additions & 4 deletions src/task/mod.rs
Original file line number Diff line number Diff line change
Expand Up @@ -160,11 +160,7 @@ cfg_default! {
mod task_locals_wrapper;

#[cfg(not(target_os = "unknown"))]
#[cfg(any(feature = "unstable", test))]
pub use spawn_blocking::spawn_blocking;
#[cfg(not(target_os = "unknown"))]
#[cfg(not(any(feature = "unstable", test)))]
pub(crate) use spawn_blocking::spawn_blocking;
}

cfg_unstable! {
Expand Down
2 changes: 0 additions & 2 deletions src/task/spawn_blocking.rs
Original file line number Diff line number Diff line change
Expand Up @@ -16,7 +16,6 @@ use crate::task::{self, JoinHandle};
/// Basic usage:
///
/// ```
/// # #[cfg(feature = "unstable")]
/// # async_std::task::block_on(async {
/// #
/// use async_std::task;
Expand All @@ -28,7 +27,6 @@ use crate::task::{self, JoinHandle};
/// #
/// # })
/// ```
#[cfg_attr(feature = "docs", doc(cfg(unstable)))]
#[inline]
pub fn spawn_blocking<F, T>(f: F) -> JoinHandle<T>
where
Expand Down