-
Notifications
You must be signed in to change notification settings - Fork 11
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
this isn't async #13
Comments
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
|
async should mean "off the event loop" IMO...but I do understand why this
|
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 it's up to you which bin to put asynchrony in I personally like to put asynchrony in the parallelism bin 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.
Good work |
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?
The text was updated successfully, but these errors were encountered: