3 ms·

I'm seeing a lot of confusion about the internals of NodeJS, so I hope to clarify: NodeJS userland is effectively single-threaded, but NodeJS is not single-thr

I'm seeing a lot of confusion about the internals of NodeJS, so I hope to clarify: NodeJS userland is effectively single-threaded, but NodeJS is not single-threaded. NodeJS outsources some event loop scheduling to libuv, and libuv is multi-threaded (by default, 4 threads, but this can be configured. See: https://medium.com/the-node-js-collection/what-you-should-know-to-really-understand-the-node-js-event-loop-and-its-metrics-c4907b19da4c https://medium.com/the-node-js-collection/what-you-should-kn... An excerpt: "Libuv by default creates a thread pool with four threads to offload asynchronous work to. Today’s operating systems already provide asynchronous interfaces for many I/O tasks (e.g. AIO on Linux). Whenever possible, libuv will use those asynchronous interfaces, avoiding usage of the thread pool. The same applies to third party subsystems like databases. Here the authors of the driver will rather use the asynchronous interface than utilizing a thread pool. In short: Only if there is no other way, the thread pool will be used for asynchronous I/O." It's possible there is some internal enforcement, inside of libuv, of timeouts, because there are some bizarre problems that come up when NodeJS is under enough load. See: "A surprising NodeJS failure mode: deterministic code becomes probabilistic under load" http://www.smashcompany.com/technology/a-surprising-nodejs-failure-mode-deterministic-code-becomes-probabilistic-under-load http://www.smashcompany.com/technology/a-surprising-nodejs-f...

iaml 9y ago
On a similar note, would this kind of offloading be feasible in browsers?
- esprehn 9y ago
  Yes, browsers already work this way today. For example in Chromium there's threads for GC, JS compilation, IO, image decoding, audio processing, video decoding, rastering, compositing, animations, indexeddb, and more. It also uses a thread pool and a task scheduler that handles prioritization both on the main thread (where the DOM is) and inside the thread pool. (ex. Handling touches is usually more important than handling xhr on the main thread). Other browsers like Servo and Firefox Quantum use the thread pool for handling layout and style tasks as well.

iaml 9y ago

On a similar note, would this kind of offloading be feasible in browsers?

esprehn 9y ago
Yes, browsers already work this way today. For example in Chromium there's threads for GC, JS compilation, IO, image decoding, audio processing, video decoding, rastering, compositing, animations, indexeddb, and more. It also uses a thread pool and a task scheduler that handles prioritization both on the main thread (where the DOM is) and inside the thread pool. (ex. Handling touches is usually more important than handling xhr on the main thread). Other browsers like Servo and Firefox Quantum use the thread pool for handling layout and style tasks as well.