How to cancel a pending Atomics.waitAsync?
Nobody has claimed this yet.
Assessment
- Difficulty
- 5/5
- Estimated time
- Over a week
- Newbie friendliness
- 25/100
- Issue type
- Feature
- Clarity
- Needs clarification
- Activity status
- Stale
- Tech stack
- javascript, wasm
- Domain
- backend-api-design
Research direction
Start by reading the Atomics.waitAsync API behavior and the WebAssembly threads proposal context described in the issue. Determine whether async waits have cancellation or garbage-collection guarantees, and document the supported behavior or the design needed to provide safe deinitialization.
Written by the indexing model from the issue text.
Description
In several scenarios, after having issued a Atomics.waitAsync(...).value.then((value) => { /* do something */ }); operation, it can happen that some kind of resource/application/page deinitialization type of activity occurs, which deinitializes parts of the Wasm app that contain e.g. the data structures for, say, a lock, semaphore or other multithreading synchronization primitive that resided at that address.
How would one ensure that if such application deinitialization does take place before the waitAsync.then() handler has been invoked, that the promise handler would never be fired (and /* do something */ should never get executed)?
At application level, I can use a separate JavaScript variable
var lockStillExists = true;
void deleteLock() {
lockStillExists = false;
}
...
Atomics.waitAsync(myInt32Array, ...).value.then((value) => { if (lockStillExists) { /* do something */ } })
to ensure that /* do something */ will never erroneously execute in case the wasm app deinitializes in between, but what happens if I want to deinitialize and let myInt32Array or other JS variables garbage collect altogether? I.e. the promise callback function (value) => { ... } will capture a scope, that would surely pin down myInt32Array and other JS vars in the scope to remain alive indefinitely (since the .then() will never resolve)?
Is there a way to cancel an async wait and/or guarantee that JS garbage collection will safely occur?
- Dominant language
- WebAssembly
- Stars
- 767
- Forks
- 54
- PR merge metrics
- No merged PRs in 30d
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from WebAssembly/threads
-
Difficulty 2/5 1-3 hours Newbie friendliness 68/100
WebAssembly/threads#254 ·
-
Difficulty 5/5 Over a week Newbie friendliness 30/100
WebAssembly/threads#253 · 6 comments ·
-
Difficulty 4/5 3-5 days Newbie friendliness 35/100
WebAssembly/threads#245 · 1 reaction ·
-
Difficulty 4/5 3-5 days Newbie friendliness 35/100
WebAssembly/threads#240 ·
-
Branch renaming Open
Difficulty 1/5 Under an hour Newbie friendliness 20/100
WebAssembly/threads#237 ·
All issues in WebAssembly/threads
Similar issues
-
bug CLI custom-model
Difficulty 2/5 1-3 hours Newbie friendliness 75/100
-
bug confirmed issue
Difficulty 2/5 1-3 hours Newbie friendliness 75/100
open-webui/open-webui#30750 · 1 comment ·
-
VerificationGate: ATTRIBUTION quote guard never matches a normal quotation (\b around the quote) Open
Difficulty 2/5 1-3 hours Newbie friendliness 75/100
danielmiessler/LifeOS#2234 ·
-
Difficulty 2/5 1-3 hours Newbie friendliness 65/100
-
bug
Difficulty 2/5 1-3 hours Newbie friendliness 75/100