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

Better management for Poisoned Locks #43

Open
gzurl opened this issue Mar 31, 2023 · 1 comment
Open

Better management for Poisoned Locks #43

gzurl opened this issue Mar 31, 2023 · 1 comment
Labels
🚀 enhancement New feature or request 💡looking for ideas Issue under discussion and looking for new ideas

Comments

@gzurl
Copy link
Contributor

gzurl commented Mar 31, 2023

Is your feature request related to a problem? Please describe.

Currently, if a lock is poisoned on the Rust side, the code will panic.
We might want to improve this behavior by returning an error.

See the original discussion at #41 (comment)

Since there is some literature written and different options about how to deal with poisoned locks, I'm opening this issue for an open discussion.

Describe the solution you'd like

@ereslibre suggested:

let mut executionctxs = WASM_RUNTIME_EXECUTIONCTXS.write().map_err(|e| format!("error: {:?}", e))?;

Describe alternatives you've considered

No response

Additional context

No response

@ereslibre
Copy link
Contributor

let mut executionctxs = WASM_RUNTIME_EXECUTIONCTXS.write().map_err(|e| format!("error: {:?}", e))?;

This is just if we keep Result<String, String>, that I think we should change to Result<String, ErrorTypes>, so that consumers don't need to process strings in errors, but can use a specific type such an enum providing better error feedback.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
🚀 enhancement New feature or request 💡looking for ideas Issue under discussion and looking for new ideas
Projects
None yet
Development

No branches or pull requests

2 participants