5 ms·

I haven't read the article, but my simplistic understanding is that Node.js for your _app_ code is single-threaded, but the async IO that happens is done via an

by girvo 9y ago

I haven't read the article, but my simplistic understanding is that Node.js for your _app_ code is single-threaded, but the async IO that happens is done via an internal thread-pool. So, number crunching in your code will pretty much always block the rest of your code (but your existing IO routines will continue, until they complete, and their callbacks can't run until your number crunching is done). I am very tired, and not thinking straight, so I've probably messed up the explanation a bit. Lately, I've been playing with libev and thread-pools together in Nim; so you write async/await stuff everywhere with futures, including number crunching, which gets delegated out to the thread pool and yields back to your main thread when it's done. It's quite nice, but I forgot how complex this stuff gets!

elmigranto 9y ago
> the async IO that happens is done via an internal thread-pool Not quite, since using threads internally (thread per IO operation) would defeat a purpose of async system, which is created specifically to not pay threading cost (context switches, etc.). In layman terms, kernel will simply invoke your C callback function when "stuff happens", and libuv propagates that to JS in platform-agnostic manner. There are still threads and thread pools in V8 and node for stuff like calculating PI (or, more realistically, password hashing and other number crunching), but that is mostly unrelated to async IO itself. Some google queries: select, poll, epoll, kqueue…
- paulddraper 9y ago
  > using threads internally (thread per IO operation) would defeat a purpose of async system Yes and no. Having single threaded JS (no matter if runtime uses epoll) allows for JS concurrency concerns to be limited to a small number of places, i.e no pre-emptive. This makes concurrency in JS easier to reason about.
- zbjornson 9y ago
  Are you sure the thread pool isn't used for IO? I thought that was it's primary use. This explanation is a bit old but I think still correct: http://stackoverflow.com/a/20346545 http://stackoverflow.com/a/20346545 and http://dailyjs.com/post/libuv http://dailyjs.com/post/libuv
  - elmigranto 9y ago
    That is true only for file system calls. Everything else is using non-blocking OS-provided mechanism. http://docs.libuv.org/en/v1.x/design.html http://docs.libuv.org/en/v1.x/design.html

by girvo 9y ago

elmigranto 9y ago

> the async IO that happens is done via an internal thread-pool Not quite, since using threads internally (thread per IO operation) would defeat a purpose of async system, which is created specifically to not pay threading cost (context switches, etc.). In layman terms, kernel will simply invoke your C callback function when "stuff happens", and libuv propagates that to JS in platform-agnostic manner. There are still threads and thread pools in V8 and node for stuff like calculating PI (or, more realistically, password hashing and other number crunching), but that is mostly unrelated to async IO itself. Some google queries: select, poll, epoll, kqueue…

paulddraper 9y ago
> using threads internally (thread per IO operation) would defeat a purpose of async system Yes and no. Having single threaded JS (no matter if runtime uses epoll) allows for JS concurrency concerns to be limited to a small number of places, i.e no pre-emptive. This makes concurrency in JS easier to reason about.
zbjornson 9y ago
Are you sure the thread pool isn't used for IO? I thought that was it's primary use. This explanation is a bit old but I think still correct: http://stackoverflow.com/a/20346545 http://stackoverflow.com/a/20346545 and http://dailyjs.com/post/libuv http://dailyjs.com/post/libuv
- elmigranto 9y ago
  That is true only for file system calls. Everything else is using non-blocking OS-provided mechanism. http://docs.libuv.org/en/v1.x/design.html http://docs.libuv.org/en/v1.x/design.html