3 ms·

>Web Workers are true threads, it's just the shared memory part that's missing. And thank god for that. I've never understood the fetish C/++ programmers have

by jnbiche 13y ago

>Web Workers are true threads, it's just the shared memory part that's missing. And thank god for that. I've never understood the fetish C/++ programmers have for shared memory, and locks, and mutexes. Erlang has a much saner approach to concurrency/parallelism, and web workers isn't terribly far away from Erlang's actor model. EDIT: That said, I thought about the idea of only allowing typed arrays to be shared, and I actually really like it. I think that's a sane way to approach shared memory in JS, and it could cover some of the use cases that web workers aren't a big help with.

dmpk2k 13y ago
> I've never understood the fetish C/++ programmers have for shared memory, and locks, and mutexes. There are some problems which are more amenable to shared mutable memory, especially when performance or memory space is a concern. And for those problems where the sharing of mutable data is not needed, forking, pointer ownership, thread-local data, and const correctness are all old concepts. No silver bullet.
rdtsc 13y ago
A lot of languages that claim to have "borrowed" from Erlang often borrow the "concurrent unit running independently communicating by a channel or mailbox" idea. Very few borrow the most amazing part -- isolated heaps for each of the lightweight processes. Web workers and Dart isolates, have that as well. I am not claiming they borrowed from Erlang, just saying they have that nice feature. See, fault tolerance was actually the #1 priority when building Erlang not high concurrency. High concurrency was there too but it was #2. Also the tough part is selling fault tolerance. Only those that have implemented large concurrent systems using shared memory models, plagued by dangling pointers, large mutable state in the middle of everything moving around, and have it fail will appreciate fault tolerance. Most will shrug it off -- "hey look, I can run language shootout's Mandelbrot 10x faster!". There is a trade-off there, of course. Just like in a real OS. If you want to fork separate processes for each request, you'll pay for fault tolerance in performance some, if instead you'd just called a callback in the same process.
haberman 13y ago
So shared memory is a terrible idea and C/C++ programmer "fetish", until JS has it and then then you "actually really like it"?
- tracker1 13y ago
  JS has web workers, not shared memory between threads.
  - haberman 13y ago
    Yes, but grandparent was reflecting on a proposal to add shared memory to web workers in the form of shared typed arrays.
- jnbiche 13y ago
  Fair criticism. But the idea of a shared typed array is appealing, just for the simplicity. If you must have shared memory in JS, this is not a bad way to do it.
fulafel 13y ago
Web Workers can actually let you pass messages at the speed of shared memory, thanks to an optimization, when using typed arrays with "transferables". So you can fling around buffers straight from a worker to the main thread without copying, pass it to WebGL without conversion etc. (The sender loses access to the buffer after it's sent, so it's still safe)

by jnbiche 13y ago

dmpk2k 13y ago

> I've never understood the fetish C/++ programmers have for shared memory, and locks, and mutexes. There are some problems which are more amenable to shared mutable memory, especially when performance or memory space is a concern. And for those problems where the sharing of mutable data is not needed, forking, pointer ownership, thread-local data, and const correctness are all old concepts. No silver bullet.

rdtsc 13y ago

A lot of languages that claim to have "borrowed" from Erlang often borrow the "concurrent unit running independently communicating by a channel or mailbox" idea. Very few borrow the most amazing part -- isolated heaps for each of the lightweight processes. Web workers and Dart isolates, have that as well. I am not claiming they borrowed from Erlang, just saying they have that nice feature. See, fault tolerance was actually the #1 priority when building Erlang not high concurrency. High concurrency was there too but it was #2. Also the tough part is selling fault tolerance. Only those that have implemented large concurrent systems using shared memory models, plagued by dangling pointers, large mutable state in the middle of everything moving around, and have it fail will appreciate fault tolerance. Most will shrug it off -- "hey look, I can run language shootout's Mandelbrot 10x faster!". There is a trade-off there, of course. Just like in a real OS. If you want to fork separate processes for each request, you'll pay for fault tolerance in performance some, if instead you'd just called a callback in the same process.

haberman 13y ago

So shared memory is a terrible idea and C/C++ programmer "fetish", until JS has it and then then you "actually really like it"?

tracker1 13y ago
JS has web workers, not shared memory between threads.
- haberman 13y ago
  Yes, but grandparent was reflecting on a proposal to add shared memory to web workers in the form of shared typed arrays.
jnbiche 13y ago
Fair criticism. But the idea of a shared typed array is appealing, just for the simplicity. If you must have shared memory in JS, this is not a bad way to do it.

fulafel 13y ago

Web Workers can actually let you pass messages at the speed of shared memory, thanks to an optimization, when using typed arrays with "transferables". So you can fling around buffers straight from a worker to the main thread without copying, pass it to WebGL without conversion etc. (The sender loses access to the buffer after it's sent, so it's still safe)