Here is a related thread you might find interesting: hashnode.com/post/is-nodejs-truly-non-blocking-ci…

I just got it properly.

Thread == Call Stack

So, JavaScript and node.js are single threaded system. They read the code line by line even though they are asynchronous. They disappears after they are read and appears again when needed.

The process of making betel :)

I'll say what I know about asynchronicity in general, someone correct me if I'm wrong. I think it's similar in Node, but I'm no Node expert.

This is a pretty complex topic.

Asynchronous code is not necessarily concurrent/parallel (and often isn't).

What async/await do is interrupt the current task at the await point, then proceed to some other task, in the same thread/process. This other task isn't interrupted until it completes or reaches an await of its own.

As you can tell, this is a limited form of asynchronicity, sometimes called 'cooperative'. Because interruptions only happen at specific points, and things aren't parallel, there is much less chance for subtle data races and no deadlocks (if one thread is used). Also, because the context switch is within the application, it is faster.

But how does this provide any benefit, if only one thread is used?

There is some parallelism. It's just that the main application code not parallel. What happens in parallel is

• I/O like files, network requests and database queries. This may be handled by the OS or some special threads that you don't have access to. These things take a lot of time, but little CPU power, so you can get your main thread much closer to 100% CPU use if you don't wait for IO (but do other things until it's ready).
• Heavy but fairly isolated computations can be performed in an isolated thread, that the main thread 'awaits' (so as said, it doesn't really wait, it just does other stuff). This is beneficial if you have more than one CPU, since the application code only occupies one.

Note that you could do asynchronous with multiple threads. In the Node case (I believe) there is one thread, but multiple program flows running interchangeably between awaits. But you could spread those (many) flows over several (few) real threads.

i think one of the best explanations is this picture

taken from itnext.io/multi-threading-and-multi-process-in-no…

It's a difference between being a singlethreaded language and just using 1 thread. The question is can you access the threads, can you control them? in js you can't it's up to the eventloop what's happening.

So you are right, u usually utilize more then 1 thread. But you are not able to access the multi-threading hence it's not a multithread language. You can however use workers with buffer arrays to use some kind of threading system.

But it's not like java or go where you start your concurrent coroutines or thread models with shared memories and resources directly.

I think Marco Alka wrote in details about this I forgot the exact title of the response. Maybe he will elaborate / correct me where I went wrong.

You can't say NodeJS is 100% single threaded. Only some part of it is single threaded

Also if you use PM2 or something you could use all of them!

Some videos that might help you:

• The Node.js Event Loop: Not So Single Threaded

• What the heck is the event loop anyway?