Live data from Hacker News

Multithreading Rust and Wasm

rustwasm.github.io

11–20 of 47 posts

Re: Multithreading Rust and Wasm

#11

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…

Thanks, I'll give that a go!

Re: Multithreading Rust and Wasm

#12
post #10
post #9

Goddamn, 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…

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

#13
post #12
post #10

Earlier 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.

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.

Re: Multithreading Rust and Wasm

#14
post #12

Earlier 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.

Even though the DOM story hasn't been figured out, firefox has recently done work to make WASM JS calls performant. So now things like Yew will probably be usable from a performance standpoint[0]. But apart from the DOM, it's good for CPU intensive things[1].

[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

#15
Nice, was just reading your issue [0]. I spent a bit of time the other day thinking how I could implement these thread ops on the JVM (JVM rambling henceforth, skip if not curious)...

First, 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).

0 - https://github.com/WebAssembly/threads/issues/106

Re: Multithreading Rust and Wasm

#16
post #12

Earlier 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.

There is a DOM story: host bindings. It just isn't implemented yet.

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

#17
post #10
post #9

Goddamn, 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…

You forgot Haskell..

Re: Multithreading Rust and Wasm

#18
post #10
post #9

Goddamn, 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…

[deleted]

Re: Multithreading Rust and Wasm

#19
post #9

Goddamn, the frequency of Rust-related articles on the front page must be really telling something positive about this language and its community.

I regularly hit a search [1] to pick up Rust related stories. Most Rust-related articles don't make the front page and most see no comment activity at all.

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

#20
post #10

Earlier 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..

And for a year or two it was Node.js.
Post reply on HN