1

I'm new to Node and try to understand the non-blocking nature of node.
In the image below I've created a high level diagram of the request.

enter image description here

As I understand, all processes from a single user for a single app run on a single thread.
What I would like to understand is the how the logic of the event loop fits in this diagram. Is the event loop the same as the processor pipeline where instructions are queued?
Imagine that we load an app page into RAM that creates a stream to read from by the program: 

readstream.on('data', function(data) {});

Instructions for creating the readstream and waiting for data to occur: does this instruction "hang" in a register (waiting for the I/O to finish) in the processor whereas in a multithreaded environment, the processor just doesn't take new instructions from the RAM until the result of the previous I/O request has been returned to the RAM?
Or is the way I see this entirely/partially wrong?

Just a supplementary (related, perhaps stupid) question: run different users on different threads on the server and isn't the single threaded benefit only for a single user?

I'm new to this type of detail, so excuse me if this question doesn't entirely make sense to you. But understanding this seems essential for me before moving forward.

html_programmer
  • 18,126
  • 18
  • 85
  • 158
  • 1
    Unfortunately almost everything about this is wrong. – Pointy Feb 25 '15 at 16:39
  • 1
    It's hard to clarify; it is literally all wrong. The event loop has nothing to do with CPU architecture - nothing at all. The concepts are totally unrelated. – Pointy Feb 25 '15 at 16:40
  • Well, I find it a hard concept to grasp currently as I'm new to do this. I read that the benefit is about single threads, which is related to the way instructions are fetched from the RAM. When instructions are executed and waiting for data to be imported, the instruction must be somewhere waiting to be fulfilled and closed, is it not? Ok if the instruction processor's pipeline is unrelated. But I can't find some readable documentation where to learn this into closer detail to help me further. Some answer would be helpful. Thanks. – html_programmer Feb 25 '15 at 16:47
  • Threads really don't have much to do with CPU architecture either. Node is a JavaScript system, and the way it works is far removed from the details of CPU architecture. What matters is how the operating system works, because that's what's directly involved, not RAM or instruction pipelines. – Pointy Feb 25 '15 at 16:51
  • @Pointy I'm baffled... most of what I read about processes / threads is related to the processor and the way multiple threads are managed when switching to make them seem to perform simultaneously. Which is what node does not, which is what I would like to understand. I will look further. Sorry if this question was dumb, perhaps I see what you see when having done more study on the topic. – html_programmer Feb 25 '15 at 16:58

2 Answers2

1

Event-driven non-blocking I/O relies on the fact that modern operating systems have a 'select' method that performs polling at the O/S level (not wasting CPU cycles). The select method allows you to register callbacks for certain I/O events. This tends to be much more efficient than the 'thread-per-connection' model commonly used in thread enabled languages. For more info, do a 'man select' on a Unix/Linux OS.

Randy Kamradt Sr.
  • 454
  • 3
  • 8
0

Threads and I/O have to do with operating system implementation and services, not CPU architecture.

Operations that involve input/output devices of any kind — mass storage, networks, serial ports, etc. — are structured as requests from the CPU to an external device that, by one of several possible mechanisms, are later satisfied.

On top of that reality, operating systems provide alternative programming models. In one model, the factual nature of input/output operations are essentially disguised such that executing programs are given an API that appears to be synchronous. In a C program, a call to the write() system call will cause the entire process to delay until the operation has completed.

Another programming model more closely exposes the asynchronous reality of the system. That's what Node uses. Operating systems provide ways to initiate long-duration asynchronous operations, along with ways for a process to either check for results or to block and wait for results. In Node, the runtime system can juggle lots of separate operations because the entire model is based on code running in response to events. An event can be a synthetic thing (such as the "event" of a Node module being loaded and run initially), or it can be something that's a result of actual asynchronous external events. In the case of input/output operations, the Node runtime waits for operating system notification and translates that into an event that causes some JavaScript code to run.

Pointy
  • 405,095
  • 59
  • 585
  • 614
  • Ooh ok I totally didn't know that this was what the OS was doing and that this was how it worked! Gratitude for clarifying, it makes sense now. – html_programmer Feb 25 '15 at 17:07