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

81–90 of 189 posts

Re: Concurrent JavaScript: It can work

#81

Post by coldtea »

pizlonator wrote: post #56
coldtea wrote: post #47

Earlier quoted context omitted.

WebKit needs tons of extra effort to keep it from being a twisted mess precisely because it uses threads.

Can you be very specific?

When told that multi-threaded access is hard and messy, "X program uses threads and it's not a mess" is not an argument -- for one because nobody said X program is a mess. Threads being messy is not a transitive property.

Nobody doing threads ever said that they are not messy or that multi-thread access and locking et al are easy.

Re: Concurrent JavaScript: It can work

#82

Post by blockoperation »

einrealist wrote: post #57

Yeah, and lets have the gazillion scripts, loaded by your usual favourite news site, spawn 10 threads each... For browsers, this is a bad idea. The biggest advantage of the event loop approach is that it is somewhat deterministic. With threads, that determinism goes out of the window. Lock-management? No way I do that for Browsers. I will quit working on client-side code if that is becoming a requirement! Threads for…

Whether it's a good addition to the language or not is debatable, but as a browser feature, it sounds terrifying. Browsers have a huge attack surface as it is (I mean, WebGL is a thing – exposing GPU drivers to random untrusted code on the internet, what a brilliant idea...), and exposing threading will only make it worse. Every single API would have to be carefully audited and made thread-safe, and I'm sure that many 'fun' bugs would crop up as a result.

Re: Concurrent JavaScript: It can work

#83

Post by kllrnohj »

alayek wrote: post #24
kllrnohj wrote: post #14

Earlier quoted context omitted.

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.

Re: Concurrent JavaScript: It can work

#84

Post by pizlonator »

bzbarsky wrote: post #71

What's not quite clear to me is whether "the cell never moves" is one of the assumptions that actually goes into making this work or not. And if it is, how that plays with a compacting or generational collector, where you do in fact want the cell to move.

From the standpoint of the concurrency scheme I'm proposing, it's OK to move the cell in the GC. Then it becomes a standard GC moving problem.

In JSC we don't move cells for other reasons, and the point of saying that they don't move is that the object model itself does not require the cell to ever move.

Re: Concurrent JavaScript: It can work

#85

Post by loftyal »

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.

How? Explain please. https://en.wikipedia.org/wiki/Concurrency_(computer_science)

"order-independent components", which makes sense for the Event loop.

Re: Concurrent JavaScript: It can work

#86

Post by chrisco255 »

stupidcar wrote: post #48
fermuch wrote: post #36

Earlier quoted context omitted.

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

Of course not, and hopefully it will come to V8, but its mere existence does not preclude enhancing JavaScript, any more than the existence of PInvoke or JNI precludes enhancing .NET and Java. When people say "JS shouldn't support feature X", when feature X is supported in every other serious language, I can't help but guess that their real problem is with JS itself, and they just don't think people should be using i…

Well for me it adds complexity to JS. One nice thing about JS is that it is single threaded and you don't have to deal with locks or inconsistencies there. An entire class of problems goes away, and since JS event loop is reasonably fast as it is, it's pretty nice not having to worry about concurrency.

Re: Concurrent JavaScript: It can work

#87

Post by amelius »

spankalee wrote: post #9
amelius wrote: post #4

Earlier quoted context omitted.

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.

Re: Concurrent JavaScript: It can work

#88

Post by coldtea »

pizlonator wrote: post #65
Jtsummers wrote: post #59

Earlier quoted context omitted.

In CS, parallelism is simultaneity. Two things are parallel if they occur at the same time. Concurrency is design, which may allow for parallelism. And may allow for preemption. Preemptive or cooperative concurrency is a design decision, both are concurrency.

"Concurrently" means "at the same time", both in English and in CS. One way to make it appear as if you have concurrency is to timeslice. One really bad way to do this is to have the timeslicing granule be computations of unbounded length with no preemption. I agree with you that it's valid to refer to event loops as a kind of concurrency. I would call it a very primitive and low-quality kind of concurrency. But it's…

>"Concurrently" means "at the same time", both in English and in CS. One way to make it appear as if you have concurrency is to timeslice.

For one, the CS literature defines concurrency as not necessarily being at the same time.

Second, timeslice, by definition, is not at the same time. Hence the need to use quotes there. Concurrently does not mean "at the same time" any more than "timeslice" implies.

>But it's not at all valid to claim, as @coldtea seems to be doing, that concurrency excludes the notion of two things happening at the same time.

I never claimed that. I wrote that concurrency is not parallelism (which it isn't), not that it excludes parallelism.

Basic timeslicing (baring any other mechanism) for example is concurrent but not parallel. Node's evented "cooperative" concurrency is also not parallel.

Re: Concurrent JavaScript: It can work

#89

Post by amelius »

pizlonator wrote: post #39
spankalee wrote: post #12

Earlier quoted context omitted.

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 defini…

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

But I agree that transferring control is a bad idea.

Re: Concurrent JavaScript: It can work

#90

Post by jensvdh »

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?

What's the point? Why not write your server directly in say Python or Java then?

I thought WASM is meant to get around the restriction that the browser only understands JS right now.

Post reply on HN