Skip to content
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

Implement precise waking on alloc targets #166

Open
yoshuawuyts opened this issue Mar 11, 2024 · 2 comments
Open

Implement precise waking on alloc targets #166

yoshuawuyts opened this issue Mar 11, 2024 · 2 comments
Labels
enhancement New feature or request

Comments

@yoshuawuyts
Copy link
Owner

#163 has introduced support for #[no_std] environments, but in order to achieve that it has implemented a less efficient version of WakerArray and WakerVec, which wake all of their child futures every time they're woken. We should implement a more efficient version of this which works on #[no_std] environments.

This is not needed for correctness; merely for efficiency. But especially on embedded environments, efficiency matters - so it really would be great if we could tackle this. Thanks!

@yoshuawuyts yoshuawuyts added the enhancement New feature or request label Mar 11, 2024
@alexmoon
Copy link
Contributor

I think that precise waking is going to require some sort of allocator. The waker context needs to be able to outlive the associated future. In no_std you could do something like a static arena of wakers you can allocate from. You would probably also want some way to define the size of that arena at compile time.

For alloc it's significantly simpler. I think the goal here should be to make ReadinessVec/ReadinessArray lock-free which would enable their use in both std and alloc contexts (and maybe improve performance at the same time).

@yoshuawuyts yoshuawuyts changed the title Implement precise waking on no_std targets Implement precise waking on alloc targets Mar 11, 2024
@max-heller
Copy link

In no_std you could do something like a static arena of wakers you can allocate from. You would probably also want some way to define the size of that arena at compile time.

I've experimented with this approach but haven't found a way to make it ergonomic. With TAIT it becomes possible to define type-inferred statics with a macro, which might help

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

3 participants