Why libuv Uses a Thread Pool for File I/O Instead of Asynchronous Disk I/O

Before discussing libuv’s thread pool, the article poses the question: in asynchronous event libraries, network I/O can use event‑driven mechanisms (e.g., epoll), but file I/O often relies on a thread pool. It then references an external article about libtorrent’s asynchronous‑disk (aio) branch, which, since 2010, has allowed multiple concurrent disk operations and introduced several performance improvements:

Disk cache can be accessed by multiple threads; a cache hit is served immediately even while other threads are refreshing data.

Data blocks need not be flushed to disk before being uploaded to peers.

Socket operations, such as SSL, can be performed in the thread pool.

The disk cache uses ARC instead of LRU, giving O(1) complexity rather than O(log n).

The cache supports multiple layers, allowing an SSD to act as a secondary cache.

The piece picker has been optimized.

The torrent list has been optimized to handle tens of thousands of torrents simultaneously.

Hashing of pieces is performed in parallel to increase download speed.

After experimenting with true asynchronous disk I/O—using various platform‑specific calls to achieve genuine async behavior—the author reverted to a thread‑pool approach after two years, citing several reasons:

Code complexity.

Poor API design.

Low implementation quality.

Weak support.

The article then lists the benefits of using a blocking‑call thread pool instead of asynchronous disk operations:

High‑level operations that decompose into multiple disk actions become easier to understand and debug.

Each disk operation is effectively asynchronous, including rename and copy.

Disk code remains platform‑independent (except on systems lacking pwritev()/preadv()).

Disk threads can use vector I/O (readv/writev), typically handling larger buffers than those allowed by macOS AIO.

It concludes that asynchronous disk I/O still faces many engineering problems, and its future remains uncertain. The article then describes libuv’s own handling of disk I/O and its thread pool:

File operations differ from socket operations; sockets use the OS’s non‑blocking APIs, while file operations use blocking functions executed in the thread pool, with results reported back to the event loop.

libuv provides a global thread pool used for all filesystem calls, user code, and DNS requests (getaddrinfo/getnameinfo). The default size is 4, configurable via the UV_THREADPOOL_SIZE environment variable, with an absolute maximum of 1024 (raised from 128 in version 1.30.0).

The pool is shared across all event loops. When a function queues work (uv_queue_work()), libuv pre‑allocates and initializes the maximum number of threads allowed, resulting in modest memory overhead (≈1 MB for 128 threads) while improving runtime thread performance.