Re:A Taste of JavaScript's New Parallel Primitives
by slavik81 on Thursday May 05, 2016 @07:16PM
(#11640441)
Forking and threading are different things. Forking creates new processes and duplicates memory. It raises entirely different issues from multi-threading, which does neither. See: http://stackoverflow.com/q/2483041/331041
They discussed forking, but did not discuss multi-threading.
Re:A Taste of JavaScript's New Parallel Primitives
by brazzledazzle on Saturday May 07, 2016 @03:46AM
(#11648764)
So for OpenSSL's RNG vs. the operating system's CSPRNG is there a difference between forking and multi-threading?
Re:A Taste of JavaScript's New Parallel Primitives
by slavik81 on Saturday May 07, 2016 @06:53PM
(#11651724)
Yes. The problem with an in-process RNG and forking is that the RNG state is duplicated, so both processes get the same sequence of numbers. Multithreading just needs locking to prevent corruption because the state is shared.
Re:A Taste of JavaScript's New Parallel Primitives
by brazzledazzle on Sunday May 08, 2016 @01:19AM
(#11652743)
Thanks for taking the time to explain.
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.