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?
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
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
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.
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 to build a dashboard or something), I know I can break up my parse into promises for each phase and that I won't be locking up other UI processing as badly during that process. So: not exactly multitasking / threading as you say, but still a handy thing to think about.