| 19:02 | <rbuckton> | Are we still meeting today? |
| 19:03 | <Mathieu Hofman> | I'm in the waiting room |
| 19:04 | <Mathieu Hofman> | maybe Shu is looking for a room |
| 19:05 | <shu> | no we're already in the room |
| 19:05 | <shu> | i don't see any people waiting to be admitted |
| 19:05 | <shu> | hmm |
| 19:05 | <shu> | let me DM you the code |
| 20:24 | <rbuckton> | It occurred to me that we don't necessarily need thread local prototypes for shared structs, per se, if we're willing to live with the prototypes themselves leaking (i.e., remaining resident in memory until the app/thread shuts down). Back when I was exploring constructor/prototype correlation via handshake, those prototypes would have leaked anyways. Lets assume a given shared struct instance is tagged with a type identity representing the constructor that produced it and that type identity is itself shared across threads. Maintaining a per-agent registry of prototypes associated with those type identities is not unlike the idea of a thread-local WASM syscall table. Within a given agent we could have [[GetPrototypeOf]] look up the prototype associated with a struct instance's type identity not unlike how we look up the prototype for 1 or "foo". That, at least, would be enough to experiment with attached behavior without requiring additional GC complexity. |
| 20:34 | <rbuckton> | On a separate note, one of the concerns I have with not having anything in JS until after this ships in WASM is that we stand to lose the ability to control how WASM shared structs interact with JS. Maybe opaque values help, but I think its entirely likely that someone like emscripten or wasm-bindgen just generates glue code that wraps opaque objects with proxies and getters/setters that call back into WASM to expose this information. I think there's an opportunity to think about how JS might actually want to leverage shared memory and come up with a cohesive story. For instance, a few months back I was exploring pick notation (i.e., the monocle-mustache operator .{) as a possible mechanism for performing atomic reads and writes of a chunk of an object. There's also the possibility we could enforce locking semantics on struct instances such that they must be owned by a Mutex/SharedMutex for which you have a lock before you can read or write to them. |
| 20:35 | <rbuckton> | These are all capabilities that require native support in JS to leverage efficiently and couldn't be employed after-the-fact without potentially breaking anyone using shared structs from WASM. |