| 00:03 | <shu> | so the upshot here is, i think: without field types, the kind of lock-free programming with shared structs will be pretty limited |
| 00:03 | <shu> | and that's probably fine, because you shouldn't be doing lock-free programming most of the time? |
| 03:18 | <rbuckton> | One of the uses for compareExchange is to implement lock-free updates (i.e., atomically compare and update, returning a value so you can see if you succeeded). Requiring locks to use compareExchange kind of defeats the purpose. |
| 18:45 | <asumu> | That's interesting, so then compareExchange, add, sub, etc. will just error on a shared struct until types are added? The issue with the boxed case is that doing the loads atomically to read the actual value has high cost? |
| 18:51 | <asumu> | BTW, on another topic there's been some development on the Wasm GC side. The idea for now is to have a minimal JS API for the MVP proposal, that won't allow attaching a prototype or reading the fields off of a GC struct from JS (more precisely, you would need to call a Wasm function to do that). Then a richer JS API would be in a separate follow-up proposal. I think that's still compatible with JS structs, in that the connection to structs could come in the follow-up proposal (there is no need for GC structs to be reflected as JS structs if the fields are not readable from JS directly as properties). But I'd like to make sure the minimal JS API won't preclude using structs in the future, by keeping the reflected Wasm GC struct as a frozen object (with no own properties) and a null, immutable prototype. Eventually the follow-up proposal could make those reflect as structs. Does that sound like it would work for future compatibility with structs? |