News for hackers. Stuff that matters.
Re:Multithreading Rust and Wasm by klarifie on Tuesday October 23, 2018 @02:31PM (#18286093)
This is analogous to different UNIX programs communicating with shmget and a synchronization primitive. It's still a multiprocess model.
Re:Multithreading Rust and Wasm by monocasa on Tuesday October 23, 2018 @03:31PM (#18286628)
At that point, the distinction between threads and processes gets really muddy even when you're not using wasm. clone(2) is just a superset of fork(2) that lets you decide whether to share memory or not (among other resources).
Re:Multithreading Rust and Wasm by namibj on Tuesday October 23, 2018 @09:29PM (#18288969)
I still think one could use a stackless clone(2) to get rid of the TLB flush when using threaded open(2). It would need to live without using the stack inside the clone however, and that's rather ugly to program.
Re:Multithreading Rust and Wasm by nemaar on Tuesday October 23, 2018 @02:50PM (#18286267)
Technically, you are right, but if multiple processes use the same shared memory is there a real, meaningful difference? You can do efficient, parallel computation in a browser, does it really matter how it is executed under the hood?
Re:Multithreading Rust and Wasm by pjmlp on Tuesday October 23, 2018 @02:47PM (#18286236)
And with the current trend of ongoing exploits actually safer than threads.
Re:Multithreading Rust and Wasm by jamesfmilne on Tuesday October 23, 2018 @02:50PM (#18286266)
Nope they are using the same SharedArrayBuffer as their memory object.