| 17:45 | <Mathieu Hofman> | Chatting with Mark yesterday, we realized that the wasm shared everything thread proposal is pretty strict about shared stuff not being able to access non shared stuff. Which brings the question, are there no use cases where shared funcs need to "call" a host function (which I assume is non-shared?). How would that work? |
| 17:52 | <shu> | that is a required use case, in fact |
| 17:52 | <shu> | that's what all the thread-local storage, thread-bound storage, and discussions of that nature orbit around |
| 17:52 | <shu> | i talked about this in the update talk as the "syscall table" |
| 17:52 | <Mathieu Hofman> | right but what I'm reading is that TLS only stored shared things? |
| 17:52 | <shu> | TLS is a table that stores unshared things |
| 17:53 | <shu> | the storage is thread-local |
| 17:53 | <shu> | err |
| 17:53 | <shu> | you can put e.g. web API JSFunctions inside them |
| 17:53 | <shu> | the JS proposal also has the no shared->unshared edges restriction (at runtime) |
| 17:54 | <Mathieu Hofman> |
That's why I'm confused |
| 17:54 | <shu> | oh that's a wasm type systems quirk, i was also confused by that |
| 17:55 | <shu> | iirc that's resolved by thread-local functions created on the Wasm/JS API layer via WebAssembly.Function(..., { thread-local: true }) showing up as shared extern refs |
| 17:55 | <shu> | "non-shared references" should be read as "references with non-shared types in the type system" |
| 17:56 | <Mathieu Hofman> | ok so a thread local function is considered "shared" |
| 17:56 | <shu> | yeah |
| 17:57 | <Mathieu Hofman> | that's weird, what happens if you get a reference to it not from TLS |
| 17:58 | <Mathieu Hofman> | aka if you attempt to call a thread-local func from a different thread |
| 17:58 | <shu> | it's thread-local |
| 17:58 | <shu> | so it's safe to access it from a different thread, it'll call whatever function that TLS "box" is bound to in the other thread |
| 17:58 | <shu> | if it's thread-bound, it'll trap from other threads |
| 17:58 | <Mathieu Hofman> | right but it materializes in wasm as just a shared func ref, no ? |
| 17:59 | <shu> | a shared externref |
| 17:59 | <shu> | i think? |
| 17:59 | <shu> | like are you saying it's weird it'll trap when called? |
| 18:00 | <Mathieu Hofman> | I'm just trying to understand the shared / unshared integration for now |
| 18:00 | <shu> | at the type system, thread-local things show up as "shared" |
| 18:04 | <Mathieu Hofman> | what slightly surprises me is that the type system doesn't seem to have a distinction between thread local and shared, which means you can end up having shared refs which are really only valid locally without a way to know |
| 18:05 | <shu> | ah |
| 18:06 | <shu> | that's a fair question |
| 18:06 | <shu> | i have no idea why not and the trade-off space there |
| 18:06 | <shu> | as an observer there's a certain deference to toolchain complexity that guides design |
| 18:06 | <shu> | you're best redirecting that question to the wasmcg folks themselves |
| 18:07 | <Mathieu Hofman> | yeah, do you know where I can ask such questions? |
| 18:08 | <shu> | https://github.com/WebAssembly/shared-everything-threads/discussions i think? |
| 18:09 | <shu> | there's certainly a lot of activity there |
| 18:09 | <Mathieu Hofman> | ah didn't realize they use GH discussion. Sorry pretty new to wasm things |
| 18:10 | <shu> | i don't like discussions |
| 18:10 | <shu> | it's just such a bizarre UI |
| 18:30 | <shu> | my favorite is that you see a reply box, and start replying |
| 18:30 | <shu> | but wait! you actually just started a new thread within the same discussion topic |
| 18:30 | <shu> | so you delete the new thread and copy over your reply to the original thread |
| 18:31 | <shu> | but wait! someone else already replied to the new thread because they were also confused |
| 19:13 | <littledan> | it's awesome to see so much advancing on the shared-everything-threads side. This should be a good basis for future JS development. |