Join GitHub today
GitHub is home to over 40 million developers working together to host and review code, manage projects, and build software together.
Sign upDefault all async support to `std::future` #1741
Conversation
This comment has been minimized.
This comment has been minimized.
Since async/await won't be on stable until 1.39 in november, perhaps we should aim to do the breaking bump then? |
This comment has been minimized.
This comment has been minimized.
|
I could go either way on that I think. I do think that we'll want to use In that sense if we were to publish/merge this now it means that local testing of this requires nightly (not that big of a deal) but the latest versions of I'm curious if others using these crates have thoughts on whether it'd be nice to land sooner rather than later given all this, I could personally go either way. |
This comment has been minimized.
This comment has been minimized.
|
Can we have support for That's a lot more idiomatic than using |
This comment has been minimized.
This comment has been minimized.
|
I haven't done a super thorough review, but it looks like you took the 0.1 code and ported it to 0.3. I think it would be better to go the other way around: take the 0.3 code and add atomic support to it. I had made a lot of improvements to the 0.3 code, which this PR gets rid of. |
yoshuawuyts left a comment
|
Looks great! -- I'd be in favor of merging this sooner rather than later (as I feel I say every time this comes up, haha) |
This comment has been minimized.
This comment has been minimized.
I think we definitely should! I added enough support for that to tests, but I'd like to work a bit more yeah to get that working as well for futures. I think it may be best to file an issue for that and track in a follow-up PR though. (or do here if I or anyone else gets time!)
Oh oops, sorry didn't mean to lose all that! Can you elaborate a bit on what optimizations the 0.3 implementation had we want to be sure to preserve? |
This comment has been minimized.
This comment has been minimized.
|
This comment has been minimized.
This comment has been minimized.
|
I took a look at the multi-threading code:
Can we punt the multithreading implementation to a future PR while we work out these issues? |
This comment has been minimized.
This comment has been minimized.
|
(In the interest of getting this merged, we can merge this as-is and I can send a follow-up PR which adds back in the optimizations) |
This comment has been minimized.
This comment has been minimized.
|
Out of curiosity, was there data showing that the optimizations were necessary? I could imagine that hundreds/thousands of promises is probably worse than one, but I'm not sure if that practically really comes up that often.
This is fundamentally required because futures produce
That's correct, and intended. (it's also a fallout of the previous point). This is useful when your computation is, for example, being produced on a foreign rayon thread. When the final notification comes in that a value is ready some small work is done to convert it to a
That sounds good, I checked in with @fitzgen and I think the procedure here is going to be:
|
This commit defaults all crates in-tree to use `std::future` by default
and none of them support the crates.io `futures` 0.1 crate any more.
This is a breaking change for `wasm-bindgen-futures` and
`wasm-bindgen-test` so they've both received a major version bump to
reflect the new defaults. Historical versions of these crates should
continue to work if necessary, but they won't receive any more
maintenance after this is merged.
The movement here liberally uses `async`/`await` to remove the need for
using any combinators on the `Future` trait. As a result many of the
crates now rely on a much more recent version of the compiler,
especially to run tests.
The `wasm-bindgen-futures` crate was updated to remove all of its
futures-related dependencies and purely use `std::future`, hopefully
improving its compatibility by not having any version compat
considerations over time. The implementations of the executors here are
relatively simple and only delve slightly into the `RawWaker` business
since there are no other stable APIs in `std::task` for wrapping these.
This commit also adds support for:
#[wasm_bindgen_test]
async fn foo() {
// ...
}
where previously you needed to pass `(async)` now that's inferred
because it's an `async fn`.
Closes #1558
Closes #1695
3c887c4
into
rustwasm:master
This comment has been minimized.
This comment has been minimized.
Yes. It's common for dominator to spawn hundreds (or even thousands) of Futures simultaneously, and the situation is even worse with animations (because hundreds of Futures can run on every frame).
Ah, okay, I see. I had wrongly assumed that it was a proper multithreading implementation (like |
This comment has been minimized.
This comment has been minimized.
Nice! If you've got time to look into reapplying the optimization that'd be great, otherwise I can try to find time as well to reimplement it. |
This comment has been minimized.
This comment has been minimized.
I already did, I'll send the PR tomorrow. |
This comment has been minimized.
This comment has been minimized.
Thanks!
#1754 now! |
alexcrichton commentedAug 28, 2019
This commit defaults all crates in-tree to use
std::futureby defaultand none of them support the crates.io
futures0.1 crate any more.This is a breaking change for
wasm-bindgen-futuresandwasm-bindgen-testso they've both received a major version bump toreflect the new defaults. Historical versions of these crates should
continue to work if necessary, but they won't receive any more
maintenance after this is merged.
The movement here liberally uses
async/awaitto remove the need forusing any combinators on the
Futuretrait. As a result many of thecrates now rely on a much more recent version of the compiler,
especially to run tests.
The
wasm-bindgen-futurescrate was updated to remove all of itsfutures-related dependencies and purely use
std::future, hopefullyimproving its compatibility by not having any version compat
considerations over time. The implementations of the executors here are
relatively simple and only delve slightly into the
RawWakerbusinesssince there are no other stable APIs in
std::taskfor wrapping these.This commit also adds support for:
where previously you needed to pass
(async)now that's inferredbecause it's an
async fn.Closes #1558
Closes #1695