Lars T Hansen

> Yes, it would also be possible to change the arguments to splats to be ints, but IMO the more specific types give a better developer experience. I can add...

Firefox currently emits an explicit alignment check for atomics. I'm guessing / predicting that these checks can be hoisted and optimized in the same way that explicit bounds checks are,...

We observed that some 32-bit ARM devices running Android would trap on unaligned floating point accesses, in fact once I started looking I didn't find any devices that didn't do...

> This all seems to be perfectly theoretical anyway. Not so, because you will (likely) be able to create an arbitrary number of asynchronous promise-based waiters without consuming significant thread...

OK. No hard feelings, it's useful to revisit issues like these to make sure we get them right anyway... Having an `Atomics.wakeAll` is less clunky than the current API, but...

An `Atomics.wakeAll` that does not return anything seems like a step backward. I don't understand what the concern is about having a trapping case for something that is almost certainly...

On 64-bit systems, in an implementation that implements waitAsync with promises without needing to start a thread for each of them, more than 2^32 waiters is likely possible, and we...

I'm actually a tiny bit exasperated here because all we're trying to do is assign meaning to a particularly nutty corner case that just needs *a* meaning, yet the discussion...

Well. I did not say i64 was a "bad idea", I said a well-defined overflow semantics seemed "slightly more appealing", clearly a matter of taste. i64 just postpones the problem:...

If we think it's a realistic possibility that more than 2^32 waiters can be woken then the count argument should also be i64.