Overhaul async and future support #3213
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
kennykerr
commented
Aug 21, 2024
| } | ||
|
|
||
| #[test] | ||
| fn switch_context() -> Result<()> { |
There was a problem hiding this comment.
I'd love a simpler way to test switching execution contexts.
Comment on lines
+15
to
+18
| // All four implementations are provided here and there is thus no need to implement this trait. | ||
| // This trait provides an abstraction over the relevant differences so that the `AsyncFuture` | ||
| // implementation below can be reused for all of them. | ||
| pub trait Async: Interface { |
There was a problem hiding this comment.
FWIW, you can use the sealed trait pattern to guarantee that there can be no external implementations of this trait. See https://rust-lang.github.io/api-guidelines/future-proofing.html
There was a problem hiding this comment.
Thanks for the tip! There are some other spots where this might be useful.
This was referenced Aug 26, 2024
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This update does a few notable things to improve async and future support in the
windowscrate.Async support in general is now provided by a crate extension rather than code generation. This approach was first introduced in Simplify how extension code for
windowscrate works #3110 and is a lot simpler to maintain as its all implemented in one place.WinRT classes that represent async execution are now generated simply as type aliases for their respective async interfaces. This greatly simplifies their definitions and makes it a lot easier to understand what's going on. This does mean they lose their identity as runtime classes but in practice this is not very consequential as all of the things you'd want to do with that identity make little sense here. WinRT classes should never have been used to represent async execution. If such a case arises, we can always bring back some limited version.
The four async interfaces still provide a blocking
getmethod but now also offerIntoFutureimplementations that may be used inasyncfunctions or blocks. The resulting sharedFutureimplementation supports multiple contexts and addresses the issue first reported in WinRT Futures should update their inner Waker #342. The implementation is somewhat inspired by WinRT Futures should update their inner Waker #342 and the execution test provided by ImplementIntoFuturefor WinRT async types #3177.