The result of the `wake` operation

The return type of wake is currently int32 (according to the proposal text it is actually the wake count "converted" to int32, which is an underspecification but let's assume standard mod-2^32 wrapping was intended). This is fine for an explicit wake count but if we pass -1 as the count to wake then there's a risk that information is lost:

• On 64-bit systems we could imagine having more than 2^32 threads, OS ulimits allowing, since once we move away from workers to real threads we could conceivably be creating a very large number of them without exhausting other resources
• If the Atomics.waitAsync proposal before TC39 is adopted then it will be possible to create a very large number of waiters irrespective of OS limits on threads, and these will be visible to wasm's wake.

Either way the wake count can exceed 2^32 and information can be lost. We can argue that especially the first case is theoretical, and that an int64 will suffice for the second case on 64-bit systems, or that this overflow really does not matter one whit, because, the programmer had it coming, but perhaps the issue here is that we should be able to signal "lost information" in a sensible way in this API.

I suggest that we change the spec so that if the result in the wake algorithm is greater than INT32_MAX then we return a cookie such as -1 or INT32_MIN or ..., or we clamp to INT32_MAX, to allow programs that care about this to detect the problem. This seems slightly more appealing than changing the return type to int64. (In JS the return type is Number, which is eventually lossy but provides a clear signal that information is lost.)

cc @bnjbvr

Start with the wake algorithm and the proposal text referenced in the issue, then review the discussion about overflow and return semantics. Done requires deciding how counts beyond INT32_MAX should be represented and updating the WebAssembly threads specification accordingly.