A Taste of JavaScript's New Parallel Primitives

Re:A Taste of JavaScript's New Parallel Primitives by spenuke on Thursday May 05, 2016 @04:21PM (#11639374)

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?

[ Parent | on HN ]

Re:A Taste of JavaScript's New Parallel Primitives by roblabla on Thursday May 05, 2016 @06:50PM (#11640284)

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

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

[ Parent | on HN ]

Re:A Taste of JavaScript's New Parallel Primitives by pfooti on Thursday May 05, 2016 @06:37PM (#11640207)

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.

[ Parent | on HN ]