Skip to content

Type error in Atomics.waitAsync in Chrome v87+ #2361

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

Closed
KiKoS0 opened this issue Nov 19, 2020 · 1 comment · Fixed by #2362
Closed

Type error in Atomics.waitAsync in Chrome v87+ #2361

KiKoS0 opened this issue Nov 19, 2020 · 1 comment · Fixed by #2362
Labels

Comments

@KiKoS0
Copy link

KiKoS0 commented Nov 19, 2020

Describe the Bug

I have a multithreaded wasm app that uses futures-channel-preview for asynchronous communication that suddenly stopped working with Chrome version 87+. I googled a bit to find out that chrome released the Atomics.waitAsync feature and that even the example i used as a reference triggers exactly the same bug.

bug stack trace

The problem turned out to be in this function:

fn wait_async(ptr: &AtomicI32, current_value: i32) -> js_sys::Promise {
// If `Atomics.waitAsync` isn't defined (as it isn't defined anywhere today)
// then we use our fallback, otherwise we use the native function.
return if Atomics::get_wait_async().is_undefined() {
crate::task::wait_async_polyfill::wait_async(ptr, current_value)
} else {
let mem = wasm_bindgen::memory().unchecked_into::<js_sys::WebAssembly::Memory>();
Atomics::wait_async(
&mem.buffer(),
ptr as *const AtomicI32 as i32 / 4,
current_value,
)
};

Since Atomics.waitAsync is now defined in Chrome, it is getting used instead of the fallback method, however the function waitAsync is expecting either a Int32Array or a BigInt64Array backed by a SharedArrayBuffer. Also it's not returning a promise anymore but an Object with 2 properties async and value. The value property can either be a string or a promise. (Source)

I fixed the bug for my app in this fork but i'm not really sure if the code is compliant for a PR, not sure if that breaks anything else and also if the other output cases should be handled aswell. I'd be happy to change it accordingly with your input though.

Steps to Reproduce

Just clone and run this example in Chrome 87+ or use the already compiled online one

Expected Behavior

A promise should be returned from wait_async() to be resolved successfully later with a call to Atomics.notify.

Actual Behavior

This error is thrown:
TypeError: #<SharedArrayBuffer> is not an int32 or BigInt64 typed array.

Additional Context

rustc 1.49.0-nightly
futures-channel-preview = "0.3.0-alpha.18"
wasm-bindgen = "0.2.68"
@KiKoS0 KiKoS0 added the bug label Nov 19, 2020
alexcrichton added a commit to alexcrichton/wasm-bindgen that referenced this issue Nov 19, 2020
Looks like Chrome implements this now and the spec has also changed
since this was first implemented. Relatively easy to update the
implementation though!

Closes rustwasm#2361
@alexcrichton
Copy link
Contributor

Thanks for the report! Looks like the spec has changed since it was first written (as is to be expected) and I hadn't had a chance to see this and get around to changing the expected API!

alexcrichton added a commit to alexcrichton/wasm-bindgen that referenced this issue Nov 19, 2020
Looks like Chrome implements this now and the spec has also changed
since this was first implemented. Relatively easy to update the
implementation though!

Closes rustwasm#2361
alexcrichton added a commit to alexcrichton/wasm-bindgen that referenced this issue Nov 19, 2020
Looks like Chrome implements this now and the spec has also changed
since this was first implemented. Relatively easy to update the
implementation though!

Closes rustwasm#2361
alexcrichton added a commit that referenced this issue Nov 19, 2020
* Update `waitAsync` signature to latest spec

Looks like Chrome implements this now and the spec has also changed
since this was first implemented. Relatively easy to update the
implementation though!

Closes #2361

* Update UI tests for new stable Rust
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants