Add async variants of Atomics.wait

[allsey87]

Atomics.waitAsync now has reasonable support in most browsers with Firefox being the notable exception, however they have a bug report for implementing it.

I used the binding for Atomics.wait as a reference and one thing that seems off to me is that the typed_array argument for the bigint varieties of these functions take an Int32Array, instead of a BigInt64Array/BigUint64Array. It seems to me that the most correct thing to do here is two make further variants of this function, e.g., add the *_biguint variants, which also take u64 as their value argument. If there is a consensus on this, I can add the variants and we can rename this PR to something like "Clean up Atomics.wait and Atomics.waitAsync".

[allsey87]

Actually, at least according to the docs that I can find, BigUintArray is not supported, only BigIntArray. In which case, a clean up is definitely needed and the comments should be adjusted since they currently suggest that BigUintArray is possible (even though the type signature only accepts Int32Array).

[daxpedda]

I don't know what happened here, but I would argue that the current wait_bigint functions are just wrong, they should take a BigInt64Array instead of a Int32Array.

But I think we don't need to add to that any further.
Also we could definitely remove the documentation around BigUint64Array.

[daxpedda]

Thanks!

[daxpedda]

I was thinking about using this here:

wasm-bindgen/crates/futures/src/task/multithread.rs

Lines 189 to 190 in 29205c5

	#[wasm_bindgen(static_method_of = Atomics, js_name = waitAsync)]
	fn wait_async(buf: &js_sys::Int32Array, index: i32, value: i32) -> WaitAsyncResult;

But it wouldn't help much because we need the binding to detect support anyway. We also want to have the custom return type to avoid the overhead of Reflect, something we won't add in js-sys because we don't do this in general there.

[allsey87]

But it wouldn't help much because we need the binding to detect support anyway. We also want to have the custom return type to avoid the overhead of Reflect, something we won't add in js-sys because we don't do this in general there.

Yep, I was thinking that/stumbled across that when I was checking whether waitAsync was already implemented.

Regarding the non-async variants of wait, shall I put together a PR that fixes type_array for the _bigint variants? It would be a breaking change, although I guess no one is using this API...

[daxpedda]

Regarding the non-async variants of wait, shall I put together a PR that fixes type_array for the _bigint variants? It would be a breaking change, although I guess no one is using this API...

Personally I would be fine with it because it looks like a broken API to me, so this is more like fixing a bug then a compatibility issue.

But I can't make that call myself.
Cc @Liamolucko, @hamza1311.

[hamza1311]

I'm fine with such breaking changes. It won't be the first time we made breaking changes to API that no one is/should be using (as an example, removing interface types comes to mind)