11–20 of 66 posts
Is this another case of "here's the code I ran" when in fact they didn't? There should be 3 lines of output, not 6! Also, the code says it will print the time taken since the start of the program, which again doesn't go with the output and the conclusion being made! Anyway, how come the output isn't in order?
> However, watch what happens if we double the number of iterations
To sum it up: node.js runs only 4 background threads. Be aware of this. No big deal really. I have multiple servers running node.js under load for 3+ years and never had an issue with this. In fact, I found it helpful. If your database is under load and is already running 4 heavy queries, not giving it any more jobs is actually a good thing.
Actually the threadpool shouldn't be a factor then, unless there are no nonblocking/async drivers for the database: internally, libuv uses its threadpool to asyncify operations for which no async/nonblocking version exists (Erlang does the same IIRC), for the most part it's filesystem operations, getaddrinfo and getnameinfo (I'm guessing it could include other stuff depending on what the underlying OS provides).
Socket or file IO should have native non-blocking APIs, so it does not need to use the threadpool.
It's worth noting that DB drivers that actually integrate with libuv are a minority - most DB divers use Node-level network APIs and are unaffected by such thread pool limits.
Is this another case of "here's the code I ran" when in fact they didn't? There should be 3 lines of output, not 6! Also, the code says it will print the time taken since the start of the program, which again doesn't go with the output and the conclusion being made! Anyway, how come the output isn't in order?
Key line before where he shows output... > However, watch what happens if we double the number of iterations
Is this another case of "here's the code I ran" when in fact they didn't? There should be 3 lines of output, not 6! Also, the code says it will print the time taken since the start of the program, which again doesn't go with the output and the conclusion being made! Anyway, how come the output isn't in order?
The order of the output is dependent on when each call finished - they run in parallel, so it's not guaranteed that functions will end in the order they were invoked.
Piece of badly engineered software conquering the world. As if more JavaScript was really something worth pursuing.
Are you aware that people like you are destroying something that was once brilliant?
HN is going through an Eternal September.
Piece of badly engineered software conquering the world. As if more JavaScript was really something worth pursuing.
Is this another case of "here's the code I ran" when in fact they didn't? There should be 3 lines of output, not 6! Also, the code says it will print the time taken since the start of the program, which again doesn't go with the output and the conclusion being made! Anyway, how come the output isn't in order?
Oops, thanks for that - seems the results from the first run of the example somehow got lost in the final version and I didn't notice. The order of the output is dependent on when each call finished - they run in parallel, so it's not guaranteed that functions will end in the order they were invoked.
For some reason I was thinking the readdir would run in series so output would go up by ~1s each time.
It's worth noting that DB drivers that actually integrate with libuv are a minority - most DB divers use Node-level network APIs and are unaffected by such thread pool limits.