Which Node.js Operations Use the libuv Thread Pool?

Which Node.js Operations Use the libuv Thread Pool?

Not all Node.js operations use the thread pool. Here is which ones do and which ones do not.

Operations That Use the Thread Pool

File system operations (most fs methods like readFile, writeFile), DNS lookups (dns.lookup specifically), some crypto operations (crypto.pbkdf2, crypto.scrypt), and some zlib operations for compression.

Operations That Do NOT Use the Thread Pool

Network I/O (TCP, UDP, HTTP) does not use the thread pool. The OS handles network I/O asynchronously through epoll (Linux), kqueue (macOS), or IOCP (Windows). This is why Node.js handles thousands of network connections efficiently.

Why the Difference

The OS provides async APIs for network I/O, so libuv uses those directly. But for file systems, DNS (via the system resolver), and certain crypto, the OS does not provide reliable async APIs, so libuv uses the thread pool to avoid blocking the main thread.

How to Tell Which Is Which

If an operation is network-related, it likely uses the OS's async I/O directly. If it involves the file system, system DNS, or certain crypto, it likely uses the thread pool. The Node.js docs and libuv source are the authoritative references.

Why This Matters

If your app does many file system operations, the 4 default thread pool threads can become a bottleneck. Increasing UV_THREADPOOL_SIZE can help. But network-heavy apps are not bottlenecked by the thread pool, since network I/O does not use it.

The Takeaway

File system operations, DNS lookups (dns.lookup), and some crypto and zlib operations use the thread pool. Network I/O does not; it uses the OS's async capabilities directly. Understanding this helps you tune UV_THREADPOOL_SIZE for your workload.