Why are programmers dead set against my concurrent Node.js runtime?

Re:Why are programmers dead set against my concurrent Node.j... by eveningcoffee on Tuesday April 12, 2016 @09:08AM (#11479174)

This code can only work if each call to `process()` is executed atomically, start-to-finish, without another call touching `result` or `left`. In any language but JS, this would be an obvious race condition. But JS guarantees that there will be no concurrent access, and plenty of third-party code relies (perhaps unknowingly) on this serial execution property.

Wow, this is very strong guaranty. Thanks for this insight.

I do not write code in JS (only small spinets when necessary), so I do not have deep knowledge in it, but it would be really interesting to know where this property is described or what books should one read today to get into JS programming.

[ Parent | on HN ]

Re:Why are programmers dead set against my concurrent Node.j... by victorNicollet on Tuesday April 12, 2016 @11:12AM (#11480227)

Not an easy read, but the ECMAScript specification is very interesting if you have the time:

http://www.ecma-international.org/ecma-262/6.0/index.html#se...

> At any point in time, there is at most one execution context that is actually executing code.

> Evaluation of code by the running execution context may be suspended at various points defined within this specification. Once the running execution context has been suspended a different execution context may become the running execution context and commence evaluating its code.

Suspending the evaluation context is triggered by executing certain constructs, some of which are obvious (calling a function suspends the caller context until that function returns) and some of which are complex (there's a nice game of context switching whenever generators are involved). The general idea is that the evaluation context decides to be suspended, rather than forced to do so by anything else (like a thread scheduler).

[ Parent | on HN ]