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

A Taste of JavaScript's New Parallel Primitives

hacks.mozilla.org

Post reply on HN
Print view View original

51–60 of 107 posts

Re: A Taste of JavaScript's New Parallel Primitives

#51

Post by Lerc »

actsasbuffoon wrote: post #25
Lerc wrote: post #21

Earlier quoted context omitted.

Why is everything-is-async so entrenched in JavaScript? I'd love to have pre-emption and blocking IO in JavaScript but it seems to have been thoroughly excluded by design. What is the reasoning behind this?

If you've ever used EventMachine in Ruby, or Twisted in Python, you've probably encountered the reason. Blocking has simple semantics, but it's hard to scale. Everything-is-async is a little more complicated, but scales nicely. The problem is when you combine the two, you only get the worst of both approaches. If most things are async, and you've only got one thread, and you block that thread, then your whole app is…

Well preemption and blocking should go hand in hand. The distinction of whether or not that's multi-threading is more of a semantic argument. I'd consider them the Amino acids that the multi-threading protein is made of.

The entirely async model means that if something accidentally endless loops, it kills everything. The only reason why we get the "This script is taking a long time" is because some preemption is provided as some magic beyond the scope of the JavaScript itself.

Re: A Taste of JavaScript's New Parallel Primitives

#52

Post by macspoofing »

schmichael wrote: post #30

> if we want JS applications on the web to continue to be viable alternatives to native applications on each platform This is where I disagree with the direction Mozilla has been going for years. I don't want the web to be a desktop app replacement with HTTP as the delivery mechanism. I'm fine with rich single page web apps, but I don't understand the reason why web apps need complete feature parity with desktop apps…

>I don't want the web to be a desktop app replacement

That ship has sailed a long time ago.

>I'm fine with rich single page web apps, but I don't understand the reason why web apps need complete feature parity with desktop apps.

Because ...?

Re: A Taste of JavaScript's New Parallel Primitives

#53

Post by CiPHPerCoder »

atoponce wrote: post #50
CiPHPerCoder wrote: post #22

Earlier quoted context omitted.

A multi-threaded JavaScript also means this becomes more troubling: https://github.com/nodejs/node/issues/5798 Node.js uses OpenSSL instead of the operating system's CSPRNG. The biggest argument for "WONTFIX" is "Node.js is single-threaded so OpenSSL fork-unsafety isn't a concern for us". If JavaScript becomes multi-threaded, it's not unreasonable to expect Node.js to follow. If it does follow, expect random numbers…

Meh. Operating system CSPRNGs can be slow, whereas userspace CSPRNGs seeded from the OS CSPRNG can be fast, fast, fast. Explain how the OpenSSL RNG is broken, and why it's a bad idea to rely on it.

That's explained in painstaking detail in the Github issue I linked to.

Re: A Taste of JavaScript's New Parallel Primitives

#54

Post by slavik81 »

CiPHPerCoder wrote: post #22
pfooti wrote: post #3

You know, I'm not entirely sure how I feel about this. On the one hand: yeah, I get that having really multithreaded stuff is pretty handy, especially for certain computationally-bound tasks. On the other hand, I quite like the single-threadedness of javascript. Promises-based systems (or async/await) give us basically cooperative multitasking anyway to break up long-running (unresponsive) threads without worrying ab…

A multi-threaded JavaScript also means this becomes more troubling: https://github.com/nodejs/node/issues/5798 Node.js uses OpenSSL instead of the operating system's CSPRNG. The biggest argument for "WONTFIX" is "Node.js is single-threaded so OpenSSL fork-unsafety isn't a concern for us". If JavaScript becomes multi-threaded, it's not unreasonable to expect Node.js to follow. If it does follow, expect random numbers…

> "Node.js is single-threaded so OpenSSL fork-unsafety isn't a concern for us"

I don't see this quote within your linked issue and, as far as I can tell, there's no discussion of multi-threading.

Re: A Taste of JavaScript's New Parallel Primitives

#55

Post by pfooti »

spenuke wrote: post #29
pfooti wrote: post #23

Earlier quoted context omitted.

Well, I'm old enough to remember coding for Mac OS 8, where "multitasking" was indeed cooperative - I had to say "oh, you can interrupt me here, if you want" at different places in my code, which meant bad actors could lock the system of course. It wasn't great. On the other hand, in the uncommon event I do have some weird javascript thing that's going to take a long time (say, parsing some ridiculously-big JSON blob…

I'm still totally ignorant of the new primitives in the original link, so maybe that's why I'm confused, but: are you saying that as of today, wrapping a big parsing job into a promise frees up the event loop? I really don't think that's the case, is it? JSON.parse is gonna be blocking/synchronous whenever it happens. Can you explain a bit more of the implementation you're describing?

Not the parsing part, but the processing part. Assume I've got a big pile of data and am calculating stuff like correlations on it. If I break the process up into chunks, I can go chunk.then(nextChunk).then(afterThat) etc etc. JSON.parse still blocks, but it's the post-processing I'm talking about.

Re: A Taste of JavaScript's New Parallel Primitives

#56

Post by taurath »

AgentME wrote: post #14
ryandvm wrote: post #10

The saving grace of JavaScript's everything-is-async, single threaded model was that it was just slightly less difficult to reason about than multiple threads and shared state. (Though I'd say that's debatable...) My guess is that, despite the sugar coating that JavaScript's async internals have received of late, writing stable multi-threaded code with JavaScript is going to be hard. JavaScript now has the safety of…

SharedArrayBuffer only allows plain typed (byte) arrays to be shared at least. Arbitrary javascript objects can't be shared, so there's a very clear division about what can get affected by other threads and what can't. You don't have to worry about whether existing libraries are thread-safe, etc.

Until the point that someone makes the SharedJSON library to store JS objects in binary that is!

Re: A Taste of JavaScript's New Parallel Primitives

#57

Post by roblabla »

spenuke wrote: post #29
pfooti wrote: post #23

Earlier quoted context omitted.

Well, I'm old enough to remember coding for Mac OS 8, where "multitasking" was indeed cooperative - I had to say "oh, you can interrupt me here, if you want" at different places in my code, which meant bad actors could lock the system of course. It wasn't great. On the other hand, in the uncommon event I do have some weird javascript thing that's going to take a long time (say, parsing some ridiculously-big JSON blob…

I'm still totally ignorant of the new primitives in the original link, so maybe that's why I'm confused, but: are you saying that as of today, wrapping a big parsing job into a promise frees up the event loop? I really don't think that's the case, is it? JSON.parse is gonna be blocking/synchronous whenever it happens. Can you explain a bit more of the implementation you're describing?

You can use setTimeout to "free up the event loop". Using setTimeout(fun, 0) will run fun after the event loop has been freed up IIRC. NodeJS has a function called setImmediate that does exactly that.

JSON.parse as implemented is going to be blocking. But it's possible to implement an asynchronous, non-blocking JSON parser

See also : http://stackoverflow.com/questions/779379/why-is-settimeoutf...

Edit : requestAnimationFrame is a better alternative to setTimeout(fun, 0), as it allows the browser to update the UI.

Re: A Taste of JavaScript's New Parallel Primitives

#58

Post by dottrap »

yoklov wrote: post #33
schmichael wrote: post #30

> if we want JS applications on the web to continue to be viable alternatives to native applications on each platform This is where I disagree with the direction Mozilla has been going for years. I don't want the web to be a desktop app replacement with HTTP as the delivery mechanism. I'm fine with rich single page web apps, but I don't understand the reason why web apps need complete feature parity with desktop apps…

One reason might be that native app distribution platforms are getting progressively more closed, whereas the web is getting/remaining open.

I might get downvoted for this, but I think it is an important point to really consider. The claim that the web is getting/remaining open is somewhat dubious. As JavaScript and web browsers get increasingly complex, it is harder for anybody to just start up and write a usable, compliant web browser from scratch, which in fact entrenches the status quo.

And why do we simply trust the existing browsers? Google has very specific goals to monetize you and Chrome can be leveraged to help that goal. Microsoft's historic fight with the web and now their current changing business goals are a reminder that their web browser goals can always change, and their current model seems more like Google. Apple is always Apple. And why should we blindly trust Mozilla? They depend on external funding to keep the foundation going to pay for a lot of the complex engineering that goes into Firefox. I'm not accusing them of anything wrong, but you can look up prior controversies about their funding sources and decisions and see people don't agree it is all rosy.

I'm suggesting the increasing technical complexity is not necessarily working towards the goal of an open web because it is entrenching the gatekeepers that can make the web browsers.

Re: A Taste of JavaScript's New Parallel Primitives

#59

Post by CiPHPerCoder »

slavik81 wrote: post #54
CiPHPerCoder wrote: post #22

Earlier quoted context omitted.

A multi-threaded JavaScript also means this becomes more troubling: https://github.com/nodejs/node/issues/5798 Node.js uses OpenSSL instead of the operating system's CSPRNG. The biggest argument for "WONTFIX" is "Node.js is single-threaded so OpenSSL fork-unsafety isn't a concern for us". If JavaScript becomes multi-threaded, it's not unreasonable to expect Node.js to follow. If it does follow, expect random numbers…

> "Node.js is single-threaded so OpenSSL fork-unsafety isn't a concern for us" I don't see this quote within your linked issue and, as far as I can tell, there's no discussion of multi-threading.

I use quotes differently than journalists. I use them to indicate "this is a separate sentence that expresses an idea mid-sentence" and to indicate tone shift, not as a quote for a specific person. I use a > prefix for direct quotes.

That exact string isn't from the Github issue, it's a summary of one argument dismissing some of the OpenSSL RNG's worst issues.

Here are two direct quotes if that's what you want:

> forking is not an issue for node.js

> The bucket list of fork-safety issues that would have to be addressed is so long that I think it's safe to say that node.js will never be fork-safe.

There was also off-ticket discussion on IRC where similar arguments were made.

Re: A Taste of JavaScript's New Parallel Primitives

#60

Post by atoponce »

CiPHPerCoder wrote: post #53
atoponce wrote: post #50

Earlier quoted context omitted.

Meh. Operating system CSPRNGs can be slow, whereas userspace CSPRNGs seeded from the OS CSPRNG can be fast, fast, fast. Explain how the OpenSSL RNG is broken, and why it's a bad idea to rely on it.

That's explained in painstaking detail in the Github issue I linked to.

Okay. I read the whole thread (ugh). Arguments for using the kernelspace CSPRNG basically boils down to this:

1. Kernelspace CSPRNGs generally don't change, are well audited, and are generally accepted to be secure.

2. Userspace CSPRNGs don't provide any additional security benefit.

3. OpenSSL is a questionable security product with it's history of vulnerabilities.

So, with that said, let's look at each of them.

For the first point, I don't fully agree. The Linux kernel CSPRNG has changed from MD5 based to SHA-1 based. I have heard chatter (I don't have a source to cite this) that it should move to SHA-256 with the recent collision threats of SHA-1. There is also a separate movement to standardize it on NIST DRBG designs (CTR_DRBG, Hash_DRBG, HMAC_DRBG- https://lkml.org/lkml/2016/4/24/28). Starting with Windows Vista, Microsoft changed their CSPRNG to FIPS 186-2 or NIST SP 800-90A (depending on Windows version), which could be hash-based or AES counter based. OpenBSD changed from using Yarrow and arcfour to ChaCha20. So, no, kernelspace CSPRNGs change all the time.

For the second point, I greatly disagree. First, you need a specific RNG to compare to. It's considered "unsafe" to use MD5 as a CSPRNG, although that would require pre-image attacks on MD5, of which it still remains secure. Additionally, a userspace AES-256-CTR_DRBG is theoretically more secure than an AES-128-CTR_DRBG design. While that matters little it terms of practical use, the reality is that AES-256 has a larger security margin than AES-128, as I understand it. Same for using SHA-256-Hash_DRBG instead of SHA-1-Hash_DRBG. Userspace CSPRNGs can be more secure than kernelspace.

Finally, as far as I know, attacks on OpenSSL have been overwhelmingly CBC padding oracle attacks, in one form or another. There have been a couple RNG vulnerabilities with OpenSSL (https://www.openssl.org/news/vulnerabilities.html), but same with say the Linux RNG (https://github.com/torvalds/linux/commit/19acc77a36970958a4a...). So, I'm not sure this is a valid point.

The biggest reason why you should use a userspace CSPRNG is performance. System RNGs generally suck. The Linux kernel can't get much faster than about 15-20 MiBps. Similarly with Mac OS X and FreeBSD. OpenBSD can get about 80 MiBps (on testing with similar hardware), but that's just painful for a single host trying to serve up HTTPS websites, when the HDD (nevermind SSDs) can read data off at 100 MiBps without much problem. The kernelspace CSPRNG can't even keep up with disk IO.

Userspace CSPRNGs can get into 200-300 MiBps without much problem, and with AES-NI (provided that you're using AES-128-CTR_DRBG), 2 GiBps (https://pthree.org/2016/03/08/linux-kernel-csprng-performanc...).

But, I do agree with one very serious concern on using userspace RNGs in general: they can introduce bugs and vulnerabilities that don't exist with the system CSPRNG. Expecting a developer to get this right, especially one who is not familiar with cryptographic pitfalls, can be a massive challenge. But this isn't the case with the OpenSSL RNG.

So, I guess I don't see the point to move the node.js CSPRNG dependency from OpenSSL to kernelspace.

Post reply on HN