Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Concurrent JavaScript: It can work

webkit.org

Post reply on HN
Print view View original

31–40 of 189 posts

Re: Concurrent JavaScript: It can work

#31

Post by christophilus »

pizlonator wrote: post #26
preek wrote: post #22

JS already has a proper concurrency model which is the event loop. What it doesn't have is a model for parallelism. It's important to understand the difference! It can be hard to grasp at first, because few people make the proper distinction. If you're new to the subject, don't take my word on it, but watch the talk "Concurrency is not parallelism" by Rob Pike[0]. It's highly recommended. Learning a language that mak…

Even loop is not concurrency. Just because concurrency and parallelism are different does not meant that concurrency and event loops are the same.

You can build concurrency on the event-loop, though, which is what the OP was probably referring to.

Re: Concurrent JavaScript: It can work

#33

Post by pizlonator »

christophilus wrote: post #31
pizlonator wrote: post #26

Earlier quoted context omitted.

Even loop is not concurrency. Just because concurrency and parallelism are different does not meant that concurrency and event loops are the same.

You can build concurrency on the event-loop, though, which is what the OP was probably referring to.

Not quite. Consider a component in your code that does this:

    for (let blah of things)
        foo(blah);
In an event loop, if things has a lot of stuff in it, this can block the event loop. Other things in the event loop won't be able to run until this completes.

With threads, this just works.

Re: Concurrent JavaScript: It can work

#34

Post by stupidcar »

preek wrote: post #22

JS already has a proper concurrency model which is the event loop. What it doesn't have is a model for parallelism. It's important to understand the difference! It can be hard to grasp at first, because few people make the proper distinction. If you're new to the subject, don't take my word on it, but watch the talk "Concurrency is not parallelism" by Rob Pike[0]. It's highly recommended. Learning a language that mak…

You've got to love computer scientists:

"Hey, there's this word 'concurrent', which means to happen at the same time, what should it mean in our field?"

"How about, 'happening in independent processes'?"

"Great! There's this other word, 'parallel', that means coexist alongside but be structurally independent. What should that mean?"

"How about, 'happening at the same time'?"

"Fantastic! OK, let's go to the pub."

Hard to believe that people get confused.

Re: Concurrent JavaScript: It can work

#35

Post by pizlonator »

stupidcar wrote: post #23
pitaj wrote: post #20

Earlier quoted context omitted.

I share your concerns about the usefulness and implementation of this concurrency strategy. In my opinion, concurrency isn't necessary for JS. If web developers want high-performance, concurrent computing, they should push for adding concurrency to WASM. I doubt concurrency could hurt JS, but I just don't see any reason for it that concurrent WASM doesn't fulfill.

And what about server developers using Node.js?

Right! It can't be the all of the cool features are done in wasm, which doesn't even have a GC yet.

Re: Concurrent JavaScript: It can work

#36

Post by fermuch »

stupidcar wrote: post #23
pitaj wrote: post #20

Earlier quoted context omitted.

I share your concerns about the usefulness and implementation of this concurrency strategy. In my opinion, concurrency isn't necessary for JS. If web developers want high-performance, concurrent computing, they should push for adding concurrency to WASM. I doubt concurrency could hurt JS, but I just don't see any reason for it that concurrent WASM doesn't fulfill.

And what about server developers using Node.js?

Is there any limitation or reason for not implementing WASM on nodejs?

Re: Concurrent JavaScript: It can work

#37

Post by pizlonator »

slackingoff2017 wrote: post #30
preek wrote: post #22

JS already has a proper concurrency model which is the event loop. What it doesn't have is a model for parallelism. It's important to understand the difference! It can be hard to grasp at first, because few people make the proper distinction. If you're new to the subject, don't take my word on it, but watch the talk "Concurrency is not parallelism" by Rob Pike[0]. It's highly recommended. Learning a language that mak…

Events and asynchronous operations are sufficient enough for a concurrency library to be built on top of JS with minimal changes. I wouldn't consider what JS has now a reasonable concurrency model but the asynchronous event handling could serve as a starting point for a source of events that run on multiple threads.

That was the state-of-the-art in OS concurrency in the early nineties. Sometimes, you would have to reboot your computer because some app forgot to yield the event loop.

It's not as bad if you have to restart your app because some task forgot to yield the event loop, but it's still bad.

Threads solve this problem comprehensively because threads get to make progress regardless of whether or not other threads are in a loop.

Re: Concurrent JavaScript: It can work

#38

Post by pizlonator »

fermuch wrote: post #36
stupidcar wrote: post #23

Earlier quoted context omitted.

And what about server developers using Node.js?

Is there any limitation or reason for not implementing WASM on nodejs?

Is there any limitation of reason for forcing people to rewrite their Node.js apps in something else just to get modern features?

Re: Concurrent JavaScript: It can work

#39

Post by pizlonator »

spankalee wrote: post #12
Jtsummers wrote: post #8

Earlier quoted context omitted.

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.

Re: Concurrent JavaScript: It can work

#40

Post by jogjayr »

pizlonator wrote: post #18
Animats wrote: post #10

Of course the language can be made to support it. Given the way Javascript is used, the question is whether supporting it will create a big mess. They have some good ideas. One is that variables can be marked as restricted to one thread. That should be the default. Other languages could benefit from that feature. Python, for example. If you want to get rid of the Global Interpreter Lock, knowing which variables can't…

I think it would be weird if objects were thread-restricted by default. Concurrency is most fun when it's easy for a thread to access an object it wants.

In fact I thought willy-nilly cross-thread access was the bane of multi-threaded programming. And also the main reason that immutability in languages such as Clojure is considered a desirable feature in support of concurrency.
Post reply on HN