Consistent sync/async handling, allow more functions to be async for wasm. #1936
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
- Better error messages - Handle failure when formatting tensors. - Explain some of the weirdness with the refcell channel - MSPC channel now handles async - Use futures_lite instead of pollster. No need to have both dependencies. - client now has read_async & read as utility. Might make it easier in the future if read_async can be removed. - No need to define async arghwere in two places
It's ~5 lines of code to just implement this.
Can also mark them Send now
|
Thanks for the PR! no-tests are failing currently. |
Codecov ReportAttention: Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## main #1936 +/- ##
==========================================
+ Coverage 84.60% 85.06% +0.46%
==========================================
Files 793 793
Lines 93814 94555 +741
==========================================
+ Hits 79368 80432 +1064
+ Misses 14446 14123 -323 ☔ View full report in Codecov by Sentry. |
nathanielsimard
requested changes
Jul 1, 2024
|
Thanks for the quick review, glad you think this can work until WASM sorts out the woeful threading situation :) Fixed the typos. |
nathanielsimard
approved these changes
Jul 2, 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.
Pull Request Template
Checklist
run-checks allscript has been executed.Changes
Currently, there is a split between wasm/non-wasm targets. Some functions are sync by default, and async just on wasm, which forces you to conditionally compile them. Other functions are always sync, but migth panic on wasm.
This change makes it so that API is consistently not async, but allows some more functions (argwhere, nonzero) to be called as async if need be. All other functions that might need to be async, now instead panic if they really cannot synchronize. This means the wasm-sync flag can be removed - things will "just work" if you use a backend with sync data reads (ndarray), and might get panics on WebGPU, telling you you really have to switch to async. When going through the trouble of async-ifying your code you can now also just keep things async, rather than having to conditionally compile & have futures block within your async loop which is generally not recommend.
Engineering wise, I tried to have the async functions now use "normal" async-ness. Before, it used some mix of a futures, and a "Reader" trait which basically implemented a small Future with continuations etc. This should be a bit more consistent. Performance wise, it all compiles away if the future resolves immediatly (even if the future is boxed).
Some other misc notes:
Testing
Burn tests, internal project using the async methods on wasm for readbacks.