I've been using async/await especially for file access.

    const fs = require('fs').promises
    const path = require('path')
    
    const filePath = path.join(__dirname, 'package.json')
    const fileContents = await fs.readFile(filePath, 'utf8')
    
    console.log(fileContents)

Well I personally would use a synchronous method rather than async for something like that where the next code path depends on the return data; if you can't get the file contents then you want to throw an error straight away.

That would seem to make sense, using readFileSync() instead.

I assume it would really do much the same thing as the await example. Is there any difference?

If they do the same thing, then what's the benefit of async/await? I guess it's that you can now write your own "fs.readFileSync()" or something like that in JavaScript when needed.

fs.readFileSync() blocks the event loop preventing any other code from being run or other events/requests from being processed. Await yields control back so that other requests can be processed while the file is being read.

Ah I see. Genius. So is there ever a use-case for NOT using the Async/Await -version of readFile()? Is fsReadSync() now just legacy which we don't need any more?

Is there an advantage to using "await fs.readFile" over "fs.readFileSync"?

You haven't blocked the entire event loop (i.e., other async functions that may be waiting on I/O) while the file is being read.

Synchronous code blocks the event loop, so in real world code you'd only use the sync-version in some special cases, like when you're reading config files before you "server.boot()" and other scenarios where it's just a one-time cost.

Though the few sync functions in the stdlib become less and less convenient, first when promises came out, then with async/await, and now with top-level await.

JS is single-threaded right so (...I think...) deadlocks are actually impossible. Although I guess you can still get stuck if two pieces of code are waiting on each other to satisfy some condition (and trading control of the sole thread) without using explicit locking.

Deadlocks can happen in any kind of concurrent system with locks. As soon as you start building & using locks with Promises, this is quite easy to happen.

That said, the need for locks in JavaScript is much less than in a typical multi-threaded language, so it's a lot easier to keep track of and avoid deadlocks, if you're even using locks at all.

Yeah, nothing about JavaScript being single threaded implies any resistance to deadlock.

It's still much harder to deadlock single-threaded code than multi-threaded code because single-threading eliminates the need for most locking, which in turn eliminates most opportunities to cause deadlocks.

I love setTimeout

What does setTimeout have to do with deadlocks?