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

111–120 of 189 posts

Re: Concurrent JavaScript: It can work

#111

Post by rmrfrmrf »

einrealist wrote: post #93
rmrfrmrf wrote: post #80

Earlier quoted context omitted.

For that matter, anyone who'd like to have "fun" with concurrency and lock management in browser-side JS is free to play around with recurring asynchronous data fetching cached in localStorage when multiple browser tabs are open. Spoiler: locks are the wrong approach and you should be relying on events/callbacks instead. Oddly enough, that's similar to my gut feeling about Threads in JS.

A browser can easily optimise HTTP or localStorage calls internally, without introducing Threads to the "userland" code.

I'm talking about a userland implementation.

Re: Concurrent JavaScript: It can work

#112

Post by api »

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?

If you have crazy high performance stuff you can do it in native modules.

Re: Concurrent JavaScript: It can work

#113

Post by spankalee »

pizlonator wrote: post #98
spankalee wrote: post #72

Earlier quoted context omitted.

Fork/join on arrays and trees would be an easier to manage model, IMO.

You can implement that on top of threads.

Of course you can. You can implement anything on top of threads, especially non-determinism, race conditions and deadlocks.

Re: Concurrent JavaScript: It can work

#114

Post by flagxor »

dbaupp wrote: post #109
flagxor wrote: post #107

Earlier quoted context omitted.

It would have been a shame if the OSes on which Firefox runs had similarly limited access to shared memory to one particular "safe" style in the spirit of paternalistic caution. Would Rust/Servo have been possible without access to the raw rope?

Rust is a relatively hands-off style of thread-safety: it protects against data races but doesn't try to get things like deadlock freedom that other more restrictive systems require. The benefits apply when using locks, or message passing or even raw atomics (and similarly to higher level libraries like data parallelism in rayon). However, Rust is also explicitly designed to allow access to the "raw rope" when abstra…

As long as we offer a similar `unsafe` option, a stronger type system around mutability+concurrency might have a range of benefits for JS. Rust's definitely has a number of virtues.

A little hard to imagine grafting onto JS though. :-)

Re: Concurrent JavaScript: It can work

#115

Post by flagxor »

spankalee wrote: post #113
pizlonator wrote: post #98

Earlier quoted context omitted.

You can implement that on top of threads.

Of course you can. You can implement anything on top of threads, especially non-determinism, race conditions and deadlocks.

Event loops have these too, they just go by different names:

* non-determinism -> order in which setTimeouts run

* race conditions -> callbacks happen in an unexpected order

* deadlock -> broken callback chain

Re: Concurrent JavaScript: It can work

#116

Post by gcb0 »

pizlonator wrote: post #38
fermuch wrote: post #36

Earlier quoted context omitted.

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?

in this case, yes, a feature that breaks backward compatibility.

So someone suggested rewriting in another language, since the new feature will not fit the only advantage nodejs have: same language as browser. The alternative is to rewrite in a type of JS that will not run on the browser either.

Re: Concurrent JavaScript: It can work

#117

Post by colordrops »

flagxor wrote: post #115
spankalee wrote: post #113

Earlier quoted context omitted.

Of course you can. You can implement anything on top of threads, especially non-determinism, race conditions and deadlocks.

Event loops have these too, they just go by different names: * non-determinism -> order in which setTimeouts run * race conditions -> callbacks happen in an unexpected order * deadlock -> broken callback chain

Are you sure that setTimeouts are run in a non-deterministic order?

Callbacks can only come back in an unexpected order if you are using I/O.

A broken callback chain is not the traditional definition of "deadlock".

Re: Concurrent JavaScript: It can work

#118

Post by dboreham »

coldtea wrote: post #81
pizlonator wrote: post #56

Earlier quoted context omitted.

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.

Oh ffs I feel like I'm back in 1994 or so...

Re: Concurrent JavaScript: It can work

#119

Post by om2 »

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.

I think the proposal was to thread-restrict variables, not objects. (Or more precisely, any variable is either restricted to a thread or guarded by a lock.) So it wouldn't actually stop you from accessing any object you want, as long as you can reach it from something in scope. But it also might not be a very useful safety guarantee.

Re: Concurrent JavaScript: It can work

#120

Post by pizlonator »

gcb0 wrote: post #116
pizlonator wrote: post #38

Earlier quoted context omitted.

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

in this case, yes, a feature that breaks backward compatibility. So someone suggested rewriting in another language, since the new feature will not fit the only advantage nodejs have: same language as browser. The alternative is to rewrite in a type of JS that will not run on the browser either.

Te proposal for concurrency in the post does not break backward compatibility.
Post reply on HN