Earlier quoted context omitted.
Thanks! That fixed that problem. Except now I get "this browser does not support passive wasm memory". There aren't any obvious javascript.options.* options for that.
Oh dear sorry about this, it's a little too non-obvious how to see the demo! I've [pushed a small commit]( https://github.com/rustwasm/wasm-bindgen/commit/f016ae5846bf... ) to update the demo to include information about browser requirements. Today this demo requires Firefox Nightly (64) and requires the `javascript.options.shared_memory` feature to be enabled. Other browsers will likely soon be able to run the demo…
Multithreading Rust and Wasm
11–20 of 47 posts
Re: Multithreading Rust and Wasm
#12Goddamn, the frequency of Rust-related articles on the front page must be really telling something positive about this language and its community.
> must be really telling something positive about this language and its community. It's because it's the new shiny thing. This basically used to be a ruby on rails post-it board, then C# for a while, then Java when Java 8 Streams were announced, then Go, etc. I am not saying it's a bad thing -- in fact I can't wait to go through that "write an OS in Rust" blog that was posted here earlier -- but no I don't think it's…
Re: Multithreading Rust and Wasm
#13Earlier quoted context omitted.
> must be really telling something positive about this language and its community. It's because it's the new shiny thing. This basically used to be a ruby on rails post-it board, then C# for a while, then Java when Java 8 Streams were announced, then Go, etc. I am not saying it's a bad thing -- in fact I can't wait to go through that "write an OS in Rust" blog that was posted here earlier -- but no I don't think it's…
It's not just because it's shiny. Rust happens to (a) be a great fit for the parts of WebAssembly that have been implemented so far (partly because it doesn't need GC), and (b) have done a really good job of building WebAssembly tooling with nicer ergonomics than other languages.
Re: Multithreading Rust and Wasm
#14Earlier quoted context omitted.
It's not just because it's shiny. Rust happens to (a) be a great fit for the parts of WebAssembly that have been implemented so far (partly because it doesn't need GC), and (b) have done a really good job of building WebAssembly tooling with nicer ergonomics than other languages.
WASM is the new and shiny also. I'm not even sure what to do with it ATM given that the DOM story still hasn't been figured out.
[0] Yew: https://github.com/DenisKolodin/yew [1] Refactoring a CPU intensive JS thing: https://hacks.mozilla.org/2018/01/oxidizing-source-maps-with...
Re: Multithreading Rust and Wasm
#15First, my project's output requires no runtime/dependencies, so I am restricted to JVM libs only. Memory is implemented as a ByteBuffer which does not have atomic access. I didn't quite understand the threads spec wrt data init on mem so I'll have to get clarification there (lock all mem? just go and pray?). The implementation will create four synthetic methods in the class: lock, unlock, wait, and wake. The class will have a field that is ConcurrentMap where the key is the mem offset being locked, and the value is an array of mutable int refs size 2, the first being lock ref count and the second being wait ref count. Imports of shared memory pass that around along w/ the ByteBuffer.
Lock will create/incr ref count and secure the lock via monitorenter on the int array (or fail if ref > 0 when just a try). Unlock will monitorexit and decr the count (removing from map if both ref counts are 0). All ops are done between this lock/unlock. Wait/wake is via wait/notify on the JVM, but JVM has no construct to say how many or if any threads were woken up on notify, so I have to keep the wait count. Incr/decr on the ref and wait vs notify (in a loop if > 1) is done as expected using wait() and notify() on the array itself. The lock, unlock, wait, and notify are done w/in concurrent map's compute making them atomic. Lock/wait lazily create the refs in the map. Unlock/notify, upon reaching 0 for both refs at the end, clear the refs out of the map.
I have looked into existing JVM constructs and this seems to be the best way (I wish I could use Guava's Striped or the like, but I have no dependency/runtime requirement on outputted class files). Countdown latches, other locks, conditions, etc were all runtime overkill. I could have better performance than a boxed-int map with some extra code but wanted to keep it simple. Granted this is all pie-in-the-sky thinking, the impl will change it for sure.
I am afraid to start an implementation because the proposal isn't further along yet (I really need some test cases in the suite to make me feel better).
Re: Multithreading Rust and Wasm
#16Earlier quoted context omitted.
It's not just because it's shiny. Rust happens to (a) be a great fit for the parts of WebAssembly that have been implemented so far (partly because it doesn't need GC), and (b) have done a really good job of building WebAssembly tooling with nicer ergonomics than other languages.
WASM is the new and shiny also. I'm not even sure what to do with it ATM given that the DOM story still hasn't been figured out.
However, that doesn't mean that you can't use it now. wasm-bindgen is essentially a polyfill for host bindings plus some other little things.
Some resources to check out if you want to learn more:
* Host bindings: https://github.com/WebAssembly/host-bindings/blob/master/pro...
* More info about web-sys (web-sys is like the raw libc for the web): https://rustwasm.github.io/wasm-bindgen/web-sys/index.html
* API documentation for web-sys: https://docs.rs/web-sys/0.3.2/web_sys/
* DOM hello world example: https://rustwasm.github.io/wasm-bindgen/examples/dom.html
* A mini MS Paint style example: https://rustwasm.github.io/wasm-bindgen/examples/paint.html
* An FM synth in WebAudio: https://rustwasm.github.io/wasm-bindgen/examples/web-audio.h...
Re: Multithreading Rust and Wasm
#17Goddamn, the frequency of Rust-related articles on the front page must be really telling something positive about this language and its community.
> must be really telling something positive about this language and its community. It's because it's the new shiny thing. This basically used to be a ruby on rails post-it board, then C# for a while, then Java when Java 8 Streams were announced, then Go, etc. I am not saying it's a bad thing -- in fact I can't wait to go through that "write an OS in Rust" blog that was posted here earlier -- but no I don't think it's…
Re: Multithreading Rust and Wasm
#18Goddamn, the frequency of Rust-related articles on the front page must be really telling something positive about this language and its community.
> must be really telling something positive about this language and its community. It's because it's the new shiny thing. This basically used to be a ruby on rails post-it board, then C# for a while, then Java when Java 8 Streams were announced, then Go, etc. I am not saying it's a bad thing -- in fact I can't wait to go through that "write an OS in Rust" blog that was posted here earlier -- but no I don't think it's…
Re: Multithreading Rust and Wasm
#19Goddamn, the frequency of Rust-related articles on the front page must be really telling something positive about this language and its community.
Lately the WASM+Rust stories see a lot of activity. Also, some 'I learned Rust and this is what I think about it' type blog posts attract comments. The rest do not. 10 hours ago: "Ask HN: Rust, anyone?" asking who is using Rust in production. No replies.
[1] https://hn.algolia.com/?query=rust&sort=byDate&prefix&page=0...
Re: Multithreading Rust and Wasm
#20Earlier quoted context omitted.
> must be really telling something positive about this language and its community. It's because it's the new shiny thing. This basically used to be a ruby on rails post-it board, then C# for a while, then Java when Java 8 Streams were announced, then Go, etc. I am not saying it's a bad thing -- in fact I can't wait to go through that "write an OS in Rust" blog that was posted here earlier -- but no I don't think it's…
You forgot Haskell..