Video: Synchronous vs Asynchronous I/O in Node.js

Anna is currently working on a project called Mongosh, a Node.js application aimed at rewriting the MongoDB shell to improve maintainability and incorporate modern JavaScript practices.

Implementing synchronous IO for network operations in Node.js is challenging because the underlying library (libuv) does not support synchronous network IO, requiring complex workarounds or reimplementation of the networking stack.

The approach using workers with atomics achieves synchronous IO by blocking the main thread using atomics.wait, while a worker thread performs the IO operation asynchronously. Once completed, the worker notifies the main thread to proceed, mimicking synchronous behavior.

The purpose of the project where Node.js is embedded into itself is to create a synchronous worker by starting a new Node.js instance on the same thread. This allows for synchronous execution without multi-threading, providing a unique way to handle certain synchronous operations.

The use of atomics.wait in browsers is limited because it blocks the main thread, which would prevent rendering and other operations, potentially degrading user experience and browser functionality.

Acceptable scenarios for using synchronous IO in Node.js include loading code required during the synchronous file system IO, writing CLI applications with limited concurrent operations, and situations where synchronous code is necessary due to API constraints.

The main reason to avoid synchronous IO in Node.js is due to performance issues. Synchronous IO can block other operations from executing, causing delays and inefficiency in processing.

The synchronous version of an IO operation might initially seem faster because it directly performs the read operation without scheduling other tasks in between. However, this can be misleading as it blocks other operations, affecting overall performance.