3 ms·
> 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 a
by 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 agoAre 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 agoThat 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