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
Provide futures::task::Spawn implementation #142
Comments
This would make us rely on futures types in the public interface, which we don't want to do. That's not only for the A spawner is also pretty simple to write and I'd prefer frameworks to ship their own if they want to. An example for the patters library would be useful, though. |
A ZST spawn impl calling out to a global function is trivial to write, I just don't see why that should be repeated 100's of times across every application that wants to call into an executor-agnostic library when it can be provided by the executor. I guess someone could publish |
@Nemo157 yes, but it explicitly rules out those types from its stability guarantees. It's precisely the open issues that make it hard for us to currently commit on these. An |
I should also say that there is also |
Yes. I want to generally write down a strategy/contribution document for such things soon (tm) to bring some clarity into this. |
The code for this would probably be along the lines of: #[derive(Debug)]
struct Spawner;
impl futures::task::Spawn for Spawner {
fn spawn_obj(&mut self, future: FutureObj<'static, ()>) -> Result<(), SpawnError> {
async_std::task::spawn(future)?; // cast the error somehow
Ok(())
}
} I agree having a separate for this would be convenient. @Nemo157 is this something you would want to author? |
Unfortunately I'm not using async-std enough in real projects to have the motivation to maintain a crate for that. |
@Nemo157 that makes sense; thanks for the quick reply! |
It doesn't seem anyone is particularly eager to implement this anytime soon. Also the |
To support executor agnostic libraries it would be useful to have a handle that can be passed to them if they require the ability to spawn new tasks.
The text was updated successfully, but these errors were encountered: