Why does fs.readFile complete in the first thread-pool wave, ahead of pbkdf2 tasks queued before it?

[ganeshdevnr]

Summary

With the default libuv thread pool size (4), I fire six crypto.pbkdf2() calls and one fs.readFile() of a small, already-cached file in the same synchronous tick. The six pbkdf2 calls are issued before the fs.readFile call. I expected the readFile callback to complete after the pbkdf2 work, but it consistently lands in the first wave of completions, while two of the pbkdf2 tasks are pushed to a later wave.

Environment

• Node.js: v22.22.3
• • OS: macOS
• • UV_THREADPOOL_SIZE: unset (default 4)

Reproduction

const crypto = require('crypto');
const fs = require('fs');

const start = Date.now();
const t = () => `+${Date.now() - start}ms`;

for (let i = 1; i <= 6; i++) {
  crypto.pbkdf2('password', 'salt', 100000, 64, 'sha512', () => {
    console.log(`pbkdf2 ${i} done at ${t()}`);
  });
}

fs.readFile(__filename, () => {
  console.log(`readFile done at ${t()}`);
});

Observed output

pbkdf2 3 done at +22ms
pbkdf2 4 done at +24ms
pbkdf2 2 done at +24ms
pbkdf2 1 done at +24ms
readFile done at +24ms
pbkdf2 5 done at +42ms
pbkdf2 6 done at +42ms

The four-then-two split for the pbkdf2 tasks matches the 4-thread pool as expected.

Question

Given that all six pbkdf2 calls are submitted before fs.readFile in the same tick, why does the readFile callback complete in the first wave (~24ms) rather than after pbkdf2 5 and 6?

I'm trying to build an accurate mental model of how the thread pool orders and schedules this work. A pointer to where in the source this ordering is determined would be much appreciated. Thanks!

[initial-d]

It is not really that fs.readFile jumps ahead of the queued pbkdf2 work. The easier mental model is:

1. The first four pbkdf2 calls occupy the four libuv worker threads.
2. The remaining queue contains roughly: pbkdf2 5, pbkdf2 6, then the first filesystem work item for readFile.
3. When the first wave of workers finishes, several workers become available at almost the same time. Two of them can start pbkdf2 5 and pbkdf2 6, and another one can start the filesystem work.
4. The filesystem work for a tiny cached file is much shorter than another PBKDF2 computation, so its completion callback can be posted back to the event loop before pbkdf2 5 and pbkdf2 6 complete.

So the ordering guarantee you were expecting is stronger than what the thread pool gives you. Submission order affects when work can start, but callback order is completion order, not submission order.

A couple of details make this more visible here:

• crypto.pbkdf2 is CPU-heavy worker-pool work.
• fs.readFile is also asynchronous filesystem work, but for a small already-cached file the actual worker task can be extremely short.
• fs.readFile may involve more than one internal filesystem operation, but the important point is the same: once one of its worker items gets a thread, it can finish quickly.

If you want to sanity-check the model, try two experiments:

UV_THREADPOOL_SIZE=1 node test.js

With one worker, the filesystem task has much less opportunity to finish beside the second PBKDF2 wave, so the output should look much closer to strict serialization.

And then increase the PBKDF2 iterations heavily. The readFile callback should still appear soon after a worker becomes available, while the later PBKDF2 callbacks drift much farther out.

The source trail to look at is Node's async crypto PBKDF2 binding queuing work into libuv, Node's fs bindings for async fs requests, and libuv's threadpool worker queue / completion queue. The key distinction is queue/start order versus completion/callback order.