Hacker News Reader

Comment by spankalee | Hacker News Reader

It's awesome to see work on concurrency, but I'd really like to se a model that didn't involve shared memory.

JavaScript on the web already has the concept of Transferrables. It'd be great to explore how user-land code could create transferrable objects and graphs of them so they could be sent between threads without threads sharing the same heap.

View on HN

As someone who writes a lot of concurrent and parallel code, I can tell you it's easier to do it if the language is not imposing artificial constraints.

Also, most kinds of concurrency models will probably require the underlying VM to support some kind of shared memory. That's what this post is about.

User-land Transferrables would obviously need to be implemented with shared memory, otherwise you could just use the existing structured clone operation.

This post isn't just about an underlying shared memory model, concurrent access to objects and variables is exposed to users, and enabled by default. That's a huge footgun that I thought the PL world was moving away from.

Threads are quite successful in the real world. I think it's because the alternatives are either harder, less capable, less scalable, or even more of a footgun.

I personally love the idea of of transferable objects, this could work very well in an event driven architecture.

It'd also be nice if immutable objects could just be shared instead of copied or transferred instead of the current situation where they are copied and then made mutable.

> instead of the current situation where they are copied and then made mutable.

Could you share an example? As far as I understand, Immutable JS uses something like a trie for structural sharing and avoids memory leaks.

When you send the result of Object.freeze() to or from a WebWorker the object is still copied and comes out the other side as fully mutable (aka, not frozen).

Immutable JS is orthogonal in this case. That's "just" a fancy wrapper on top of a bunch of regular, mutable JS objects that makes it look immutable. It's not truly immutable to the runtime, and has no special interaction with webworkers as a result. It gets deep copied just like any other object.

Sorry, but we need shared memory for fast sharing of large immutable data structures.

Then add immutable objects to JS, which enable a host of other optimizations and are useful in single-threaded contexts too.

Shared-memory multithreading is just very difficult to use correctly. Actor-style concurrency hasn't really caught on (possibly because of the poor performance of workers and postMessage), but there is probably a middle ground that's easier for developers to get right.

I don't think it is a good idea to stray away from the bare metal in this case. We're trying to bootstrap other languages on top of JS. They can introduce their own abstractions to shield off the programmer. Just my 2ct.

JS already supports immutable objects, by using Object.freeze().

That doesn't really make things immutable. Even ignoring the deep vs shallow issue, consider what effect Object.freeze has on a JS Map (hint: none, really; you can still add/remove things).

Right, that's where libraries like ImmutableJS come in.

That's not deeply immutable like you'd want for sharing objects across threads, or even for using in contexts like React and Redux.

Not too hard to call Object.freeze() recursively to get the deep immutability you need. And of course there's ImmutableJS for other immutable data structures.

Shared memory could be hidden from the users. Passing objects would really be passing control of objects. If process A creates object a, and passes it to process B, no copying has to happen if the underlying mechanism uses shared memory and access control to effect the transfer (a change of owner).

Yes. Presumably transferrable objects would have to be created on a shared heap. Non-transferrables would live on thread-local heaps.

I find that thinking about multiple heaps is harder than thinking about threads. (Ever programmed with scoped memory? It's a nightmare.)

I find that thinking about transferrables is harder than thinking about threads. It's gross that an object suddenly loses all of its state just to give that object to another thread. Then, other parts of your code that still want access to that data have to do things that are definitely more gross than acquiring a lock.

You don't need locks to access immutable objects (except perhaps for garbage collection).

But I agree that transferring control is a bad idea.

Reply on news.ycombinator.com