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

Thread-local error scopes #5375

Open
kpreid opened this issue Mar 10, 2024 · 2 comments
Open

Thread-local error scopes #5375

kpreid opened this issue Mar 10, 2024 · 2 comments
Labels
area: api Issues related to API surface type: enhancement New feature or request

Comments

@kpreid
Copy link
Contributor

kpreid commented Mar 10, 2024

Is your feature request related to a problem? Please describe.
It should be possible to catch errors in a manner which is compatible with multi-threaded use of a wgpu::Device. The current push_error_scope() and pop_error_scope() use a scope stack global to the Device and thus would require a mutex to be used correctly from a program where multiple threads access the Device or Queue.

My own application for this is catching shader compilation errors to allow shader reloading during development without aborting the program on any error.

Describe the solution you'd like
#3767 already says that

This actually wasn't really previously defined - webgpu.h we decided they're going to be thread local. We need to redefine the api in wgpu to use a thread local.

which seems like a fine solution, but that's labeled as a documentation issue, so I'm filing this issue to make sure the functional change isn't overlooked.

It would also be good if the Rust interface to these error scopes was a "RAII" guard type rather than a pair of push and pop, to ensure correct cleanup on unwinding and to make push-without-pop/pop-without-push mistakes unlikely.

@cwfitzgerald
Copy link
Member

With it being a thread local, I was planning on it being a callback.

@kpreid
Copy link
Contributor Author

kpreid commented Mar 11, 2024

Sure, that's stricter and it's unlikely to be too inflexible.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area: api Issues related to API surface type: enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

2 participants