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

Should we expose task::AtomicWaker? #354

Open
yoshuawuyts opened this issue Oct 16, 2019 · 2 comments
Open

Should we expose task::AtomicWaker? #354

yoshuawuyts opened this issue Oct 16, 2019 · 2 comments
Labels
api design Open design questions feedback wanted Needs feedback from users

Comments

@yoshuawuyts
Copy link
Contributor

As per async-rs/futures-timer#39 it seems there are some scenarios where having an AtomicWaker type available would be useful.

It's somewhat niche, but I was wondering if it would perhaps make sense to expose it? Thoughts?

If we do we should probably create a separate crate so we can share the impl with futures-timer. Thanks!

@yoshuawuyts yoshuawuyts added feedback wanted Needs feedback from users api design Open design questions labels Oct 16, 2019
@skade
Copy link
Collaborator

skade commented Oct 17, 2019

Hm, I'm not quite sure if we should expose that or if we should maybe have a second library as a "futures development kit". Though futures-util is already that.

@ghost
Copy link

ghost commented Oct 17, 2019

Note that a good chunk of async-std uses no I/O and no dependencies (or just really small dependencies). Perhaps we should think of factoring that out into async-core or putting everything else behind a feature flag (perhaps named std).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
api design Open design questions feedback wanted Needs feedback from users
Projects
None yet
Development

No branches or pull requests

2 participants