3

I was under the impression that I/O in node (in particular fs's file I/O) is carried out by using native async (i.e., event-based) APIs of the operating system. However the following comment (taken from https://nodejs.org/api/fs.html#threadpool-usage) suggests otherwise:

The promise APIs use the underlying Node.js threadpool to perform file system operations off the event loop thread. These operations are not synchronized or threadsafe. Care must be taken when performing multiple concurrent modifications on the same file or data corruption may occur.

The quoted text brings the following hypothesis: fs uses a blocking I/O API of the operating system (hence the need for a thread-pool), which, in turn, raises this concern/question:

In node can an I/O-intensive program get blocked/timeout/error-out due to lack of enough threads?

Itay Maman
  • 30,277
  • 10
  • 88
  • 118
  • Note the same admonition "off the event loop thread" repeats for the Callback API too in the same document. – AKX Aug 22 '22 at 12:48
  • But anyway, it looks like the answer is "yes", based on https://nodejs.org/api/cli.html#uv_threadpool_sizesize – AKX Aug 22 '22 at 12:50
  • (as in "yes, it can get blocked", ahem...) – AKX Aug 22 '22 at 12:58
  • Looking at only the title: yes, it's truly asynchronous _with respect to the scripting context_. The last line of your question body seems to be your actual question. You're asking about _thread pool exhaustion_. See [How Nodejs's internal threadpool works exactly?](https://stackoverflow.com/a/29472222/1563833) ... and probably change your title. – Wyck Aug 22 '22 at 14:10

0 Answers0