14 ms·
Quick notes... The threads feature is in proposed status vs others that are in implementation status [0], but I assume this has been implemented before things l
by kodablah 8y ago
Quick notes... The threads feature is in proposed status vs others that are in implementation status [0], but I assume this has been implemented before things like multi-value. I wonder why threads first, I assume just for experimentation. It should be noted that threads are essentially atomic memory accesses and wait/notify, nothing for starting a worker inside of WASM or anything, that is still in JS land. The test cases don't appear to include wait/wake nor does the test case interpreter that I saw [1]. Also, "Report issues" in the blog post links to https://TBD https://TBD.
0 - https://github.com/WebAssembly/proposals https://github.com/WebAssembly/proposals
1 - https://github.com/WebAssembly/threads https://github.com/WebAssembly/threads
- tree_of_item 8y agoThe example in the article creates a thread. Is that what you mean by "starting a worker"? Because it does seem to be able to do that.
- markdog12 8y agoJust to clarify, it creates Web Workers with JavaScript which share a WebAssembly instance. This plumbing is done automatically when compiled with Emscripten with the correct flags. You can't just take code that spawns threads, create and run a single WebAssembly instance and have it work without something like Emscripten that will do this plumbing for you. It must be done via Web Workers, which are heavyweight, so you wouldn't want to be spawning lots of them.
- deleted 8y ago[deleted]
- danShumway 8y agoMy understanding is that the atomic memory operations you're talking about are a big step towards enabling more interesting features in the future. I did a glancing read of the overall spec a while back and I remember seeing a few asides to the effect of "we'll have to tackle this as part of the threads effort." Take it with a grain of salt though, I'm still digging into this stuff.
- kodablah 8y agoIt is a big step, and leaving thread management up to the host system is ideal even in non-web contexts. I wouldn't expect there to be any larger threads effort beyond this at least any time soon.