A Taste of JavaScript's New Parallel Primitives

Linux got threads in 1996 when kernel 2.0 introduced the "clone" syscall, allowing multiple processes to share address space. LinuxThreads was built on top of this to implement the pthreads api.

I'm curious about 2 things:

1. How is the accidental modification of random JS objects from multiple threads prevented - that is, how is the communication restricted to explicitly shared memory? Is it done by using OS process underneath?

2. Exposing atomics greatly diminishes the effectiveness of automated race detection tools. Is there a specific rationale for not exposing an interface along the lines of Cilk instead - say, a parallel for loop and a parallel function call that can be waited for? The mandelbrot example looks like it could be handled just fine (meaning, just as efficiently and with a bit less code) with a parallel for loop with what OpenMP calls a dynamic scheduling policy (so an atomic counter hidden in its guts.)

There do exist tasks which can be handled more efficiently using raw atomics than using a Cilk-like interface, but in my experience they are the exception rather than the rule; on the other hand parallelism bugs are the rule rather than the exception, and so effective automated debugging tools are a godsend.

Cilk comes with great race detection tools and these can be developed for any system with a similar interface; the thing enabling this is that a Cilk program's task dependency graph is a fork-join graph, whereas with atomics it's a generic DAG and the number of task orderings an automated debugging tool has to try with a DAG is potentially very large, whereas with a fork-join graph it's always just two orderings. I wrote about it here http://yosefk.com/blog/checkedthreads-bug-free-shared-memory... - my point though isn't to plug my own Cilk knock-off that I present in that post but to elaborate on the benefits of a Cilk-like interface relatively to raw atomics.

1. You can't ever get a reference to regular objects that exist in other threads (workers). Communication with workers is limited to sending strings, copies of JSON objects, transfers of typed arrays, and references to SharedArrayBuffers.

2. I assume it was done at a low level so that multi-threaded C++ could be compiled to javascript (asm.js/WebAssembly).

If the problem that this is trying to solve is that `postMessage` is slow and you can't transfer slices of arrays, then perhaps they should solve it by speeding up `postMessage` and making array slicing cheap? Forcing a shared-memory concurrency model into JavaScript seems like a bit of an overreaction.

>Trying to make the browser ideal for both browsing content, and rendering rich application UIs bloats the browser.

Maybe, maybe not - depends on how you define bloat. Modern operating systems, mobile and desktop, are magnitudes larger than their counterparts from years ago, are they bloated because they are bigger?

Having a more feature-rich browser doesn't make a browser 'bloated' - it makes it more feature-rich.

>Firefox could use a LOT more developer time spent on improving performance and reducing the memory footprint.

That's already happening, except browser performance is now focused on improving rendering engines and js engines to enable rich applications, because every modern browser is already very good at rendering 'simple', non-RIA, pages.

>For example, typically the F1 key is the "Help" key. So

Woah woah. Giving web applications capabilities that match those of native desktop applications, doesn't mean mimicking every desktop convention. The Web doesn't work with function keys, that's a convention that arose largely from platform limitations - so F1 doesn't mean 'Help' in the Web, just like F1 doesn't mean help in your CLI either. What's wrong with that?

>For all the talk about how X11 remoting doesn't work over the Internet

Anything can work - the problem is that there is no universal platform accessible to consumers to enable X11 streaming. On the other hand, almost every computing device these days provides an HTML/CSS/JS rendering engine. That's why developers want to build on top of the web-stack. So through a quirk of history that's what we ended up with - in an alternate universe, maybe the standard for rich web applications are Java Applets, or ActiveX, or X11, or SSH, or whatever. That's not the world we live in.

>With web apps, the experience is all over the damn place.

Sure, and you can go crazy, but there are conventions. For example, the way links look and behave is intuitive. I've built desktop and web applications, and there is a core 'feel' that all web-applications share because the browser takes care of so much of the behaviour and provides the base widgets and the framework. Things like the way links look, that they are underlined when you hover over them and your cursor changes, that you can right-click on a link and open in a new window/tab, how cut-and-paste and text-highlight is handled, drag-and-drop, (browser) zoom, how fullscreen works. Yes, any given page can override some of those of behaviors, but then again, so can a 'native' app.