Repository navigation
this isn't async #13
Description
Activity
Correct, it avoids blocking the event loop for long periods of time if you know you're going to be stringifying a massive object graph. If you want to process on a different thread you can use a child process, in which case you wouldn't need this library.
yes that makes sense...IMO...and I mean no malice..I think it would be
better to moniker this lib "streaming json" or what not
On Oct 14, 2015 8:34 AM, "Stephen Commisso" notifications@github.com
wrote:Correct, it avoids blocking the event loop for long periods of time if you
know you're going to be stringifying a massive object graph.—
Reply to this email directly or view it on GitHub
#13 (comment).async should mean "off the event loop" IMO...but I do understand why this
lib exists and do believe it serves a purpose
On Oct 14, 2015 10:22 AM, "Alexander Mills" alex@oresoftware.com wrote:yes that makes sense...IMO...and I mean no malice..I think it would be
better to moniker this lib "streaming json" or what not
On Oct 14, 2015 8:34 AM, "Stephen Commisso" notifications@github.com
wrote:Correct, it avoids blocking the event loop for long periods of time if
you know you're going to be stringifying a massive object graph.—
Reply to this email directly or view it on GitHub
#13 (comment)
.Asynchrony doesn't necessitate multithreading such as with Web Workers (which would be off the event loop). You're probably looking for the term "Concurrency".
actually, mildly disagree. true parallelism means running on sep processors simultaneously. async and concurrency are basically the same concept, but there is also: "all parallel operations are concurrent but not all concurrent operations are parallel." so concurrency is a subset of parallelism.
there can only be two concepts:
concurrency
parallelismit's up to you which bin to put asynchrony in
I personally like to put asynchrony in the parallelism bin
but it sounds like you like to put it in the concurrency bin, where concurrency in Node.js can be achieved by process.nextTick and setImmediate. You might actually be more consistent by doing this.and i think that's fair to put async in the concurrency bin. but I actually think it's also consistent to reserve the term "async" for operations that involve async I/O and the threadpool in V8 that supports the non-blocking I/O, which on any multiprocessor machine should be considered "parallel".
it could be, however, that async operations could never be achieved without setImmediate and process.nextTick in combination with the V8 threadpool, (I don't know the internals that well) and that would make things more interesting for the purposes of this discussion.
in other words, async is the biggest concept in Node.js and it completely relies on the V8 threadpool and has everything to do with I/O operations. so it's somewhat deceptive to start using the term async to describe the concurrency abilities of the JS event loop. that's why I think async should be thrown into the parallelism bin WRT to the node.js ecosystem.
This conversation can scare adopters of this library if not answered and closed. So, here goes my thoughts.
- The fundamental concept of what async means in JavaScript is at debate here. The library works as intended by author
- I read the code - it recursively goes through properties in an object and performs stringify in batches
- This is in line with what most developers in JS are used to the concept of async (heck even async library works this way!)
- If you've got a large object that's blocking event loop for stringification, this module will fix that.
Good work
Reacted by vignesh anand, Joseph Turbin, Sebastian, Valerii Maslenykov, Ben Allfree and Dmytro ParzhytskyiReacted by Ben AllfreeReacted by Ben Allfree and Jürgen LöhelReacted by Ben Allfree
I am confused by this lib - looking at the code - it doesn't seem to run off of the main thread - it just uses process.nextTick or setImmediate to delay processing?