Hey Thamaraiselvam j, thank you for mentioning me.

Let me start at a higher level. What is "Multi Processor". Usually, when talking about a processor, we can mean one of two things. In SE, a processor is an algorithm which takes data, does some calculations on it, and outputs transformed data. However, for a layman, a processor is the central computing chip in your computer, and I think that's what you mean here. A "Multi-Processor" would be a processor chip with several cores, which can execute code simultaneously and independently from each other.

Now that we have hardware, which can work on things in parallel, let's take a look at the software side. When executing any program, like node.exe, the program gets started in a "process". We would call it a single process, because there is only one. In addition, at the beginning, all processes start out as "Single Threaded", because they can only execute one single command at a time. However, one process can start to create more threads, so that it can do more things in parallel. Ideally, each thread is executed on a different core on our multi(-core) processor, so everything is really parallel.

However, using several threads is not always sufficient. There are many different reasons to go one step further, and instead of creating several threads inside one process actually create a whole new process. Creating new processes as opposed to threads has different advantages and disadvantages, so when writing software, the pros and cons should be carefully considered. In general, though, the advantages sum up to threads being a lot more light-weight, needed fewer resources and starting up quicker. Also, they share memory between each other, so they can quickly communicate. Processes, on the other hand, are entirely separated from each other, which means they need more resources and time to start. If they need to communicate between each other, they need external means, like the IPC mechanism of the operating system, sockets, or similar. The advantage of processes, though, is that one process may die without killing all others - which is why for example modern browsers use one process per tab. Each process can have more than one thread internally, so that both variants can be mixed.

How does the situation look for JS and NodeJS? As j already mentioned, it is important to differentiate between the language and the runtime (NodeJS or any browser in general). JS as a language does not have multi-threading. It depends on a different mechanism, async execution, which yields a lot of benefits, especially for UI (and IO) scenarios, which is what JS was created for. The JS runtime usually uses multiple threads and kernel mechanisms (epoll, kqueue, IOCP, event ports) to keep track of things, so that the async execution in JS works the way it does.

What does async execution mean? Think about writing a simple program. A JS execution block is usually read, just like a book, from top to bottom. Every command is immediately executed. However, sometimes executing a command would mean waiting for an external component. For example when writing a server, listening for clients connecting would mean waiting for clients. That's bad, because we might want to do something else, too, like writing logs, preparing files, handling another client, etc. That's why the JS runtime has an event-loop. Think of the event-loop as a todo-list. Whenever the JS runtime encounters a JS command which would make it wait, it writes an entry on its todo and continues executing JS.

const fs = require('fs'); // executed immediately

console.log('Hello!'); // executed immediately

fs.readFile('long_file.txt', // executed immediately
  (err, data) => { // written to todo-list, for when the file was read
    console.log('File read done!');
  }
);

console.log('The End!'); // executed immediately

The above program will write the following to the console:

Hello!
The End!
File read done!

The JS runtime executed everything from top to bottom and wrote an entry on its todo-list for the file-read. Once the JS runtime reaches the end of the current execution block, it takes a look at its todo-list. It will then work on the top-most item which was not crossed out, yet, and then crosses it out. The above program's todo-list would initially look like this:

- execute main program

After going through the program once, the list would change to this:

- ~~execute main program~~
- check if file was read

If the file was not read, yet, the JS code for reading a file will add a new entry to the todo-list:

- ~~execute main program~~
- ~~check if file was read and execute the handler~~
- check if file was read and execute the handler

The program will terminate once all items on the todo-list have been crossed out. Fun fact: Your operating system (OS) does something similar!

From what I just told you, you should easily be able to answer your own questions!

Assume if multiple request comes in and all are trying to access do an asynchronous then Event loop process them one by one or it will process all in Parallel?

The server implementation of NodeJS creates todo-list items for all requests. They are worked on in sequence, however, if the requests, in order to be responded to, needs to do an async task, like reading a file, then the JS runtime will just put them on the todo-list for later and start working on a different request. So, NodeJS can work on multiple requests in parallel, even though JS itself is single-threaded. All thanks to the JS runtime having to wait for IO tasks. As a result, JS is very good at doing IO and handling many many requests simultaneously.

Can [NodeJS] handle multiple Processes?

Yes! JS can only be single-threaded per process, but we can just spawn a second process and execute one program twice. Even better than just executing the program twice, NodeJS offers us an API in order to do so with many benefits. For example, when using the cluster module, we can create a web server in all processes and let all of them listen on the same port. The NodeJS module handles the port conflict for us under the hood, and even exposes if a process was executed, or spawned by another NodeJS process (in a master->worker relationship). I already created an example in a different question, and I invite you to read it there:

Put simple we first have to define where we are. We talk about threads in the OS realm.

• In the OS realm one Process can have N threads.
• Threads usually have copies of the data they need to process

Single threaded means that you cannot spawn extra threads (you can work around with workers though, even really move not copy certain data-structures into the worker 'thread' memory)

So you have 1 thread that does all your executions that's why it's blocking and as long as this thread has work todo your event-loop won't get triggered. The evenloop however has it's own thread-pool because this is usually done over the runtime which is embedded in the OS.

So the eventloop most likely does multithreading to do parallel processing.

The main confusion to me stems from the difference between JS (language) and Node (runtime).

And the concept of Single-threaded just tells you that you cannot spawn multithreading manually. But a Worker is it's own process so you can multi-process but you cannot 'share state'.

this is how far I will lean out of the window in the explanations ;D ... I am not really a JS dev but Marco Alka to my understanding could correct my statements and/or add clarifications.