-
Notifications
You must be signed in to change notification settings - Fork 962
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
Ensure the BufferMapCallback is always called. #2848
Conversation
I added this to the changelog because the PR template says so, but I wouldn't be offended if this type of plumbing isn't changelog-worthy! |
Hm, I just realized that |
I updated the PR to be more principled about invoking the callback outside of the lock in buffer_map_async. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This all makes sense - thank you!
There are a few things that I think need to be addressed.
507fa30
to
6156d97
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good, thank you! Just a few requests.
This solves two issues on the Gecko side: - The callback cleans up after itself (the user data is deleted at the end of the callback), so dropping the callback without calling it is a memory leak. I can't think of a better way to implement this on the C++ side since there can be any number of callback at any time living for an unspecified amount of time. - This makes it easier to implement the error reporting of the WebGPU spec.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks!
Checklist
cargo clippy
.RUSTFLAGS=--cfg=web_sys_unstable_apis cargo clippy --target wasm32-unknown-unknown
if applicable.Connections
WebGPU specification
Description
This PR enforces that the mapping callback is always called (be it with an error). It does so by calling it manually in more places (with corresponding error codes) and by catching the rest in the callback's destructor.
This solves two issues on the Gecko side:
Note that when the callback is fired by its
Drop
impl, there is no guarantee that it happens outside of the locks. If that's a big issue, we could instead panic in the drop impl and be very careful about the control flow.Also, the WebGPU spec specifies what should happen when destroying a buffer that is mapped or pending. The easiest way to conform to that is to just call unmap. I suspect that it will also avoid issues with wgpu itself?
Testing
None.