Ben Smith
Ben Smith
In the CG we discussed bringing up throwing an exception on INT32_MAX in JS too.
True, I suppose we didn't really say where. Though we were undecided as a group about whether to switch wake count to i64 or keep at i32.
We discussed this in the Nov 28 CG, and decided to go back to 32-bit w/ trapping on overflow.
> Is this something we can change without breaking the web? I think option 2 should be safe since it's just loosening a restriction on a module that would otherwise...
Of all of these, I think I prefer `memory.atomic.wait32`. It keeps the precedent that we prefix with `memory.`, and aligns well with things like `i64.atomic.store32`. It's not a particularly pretty...
> @rossberg will the continuations be stealable/transferable between Web Workers to allow for a scheduler per Web Worker (and one on the main UI thread) to work steal? I'm guessing...
This is the intention of the [wasm-c-api](https://github.com/WebAssembly/wasm-c-api) proposal, to provide a C and C++ API for standardizing access to a wasm engine. I think you're right that we'll want to...
I think that's a good way to start. These should be treated as proposals, so should follow the normal proposal process. We'll need to decide how to interpret some of...
Just got back from leave. Any progress on these?
Yep, adding an `i32.bswap` was discussed a while back (see [FutureFeatures.md](https://github.com/WebAssembly/design/blob/master/FutureFeatures.md#additional-integer-operators)) and could be a nice small proposal.