How non-blocking I/O works with channels

Question

I want to know how the engine in node.js know when to call and execute the queued operation. I understand that node.js is single threaded and uses asynchronous non-blocking to execute operations.

But let's say you are calling something from the database and node.js queues the operation and doesn't wait for this to execute further lines of code. Being single thread it stores the data in channels(if I am not wrong). But how does the server know that the network isn't busy and it is the right time to execute the queued operation.

Or it executes the queued operation at the end of the program. This can't be the case. So I am curious to know what happens under the hood and how does the node server know when to execute the queued operation.

When you say "with channels", what exactly are you talking about? A "channel" isn't a known node.js concept so we need to know what you mean by that. — jfriend00, May 08 '18 at 17:49
From what I read on the internet, Non-blocking IO works with channels, a thread can read/write piece of data in channels without blocking IO for the rest of the data — , May 08 '18 at 18:04
There is no "channels" concept in node.js - at least that's not a term that node.js uses itself anywhere. Not sure where you read that or what they meant by that. — jfriend00, May 08 '18 at 18:06
http://tutorials.jenkov.com/java-nio/nio-vs-io.html. Read it hear it says in the blocking vs non-blocking section it says "A thread can request that some data be written to a channel" — , May 08 '18 at 18:10
That tutorial is talking about **Java**, not Javascript. Nothing at all to do with node.js. — jfriend00, May 08 '18 at 18:12
I beleive that the concept should be simillar in javascipt also. So isn't it that non-blocking is a concept and it should apply to all domains — , May 08 '18 at 18:19
Not really. The "channels" concept in that tutorial is something that library implements itself. It's not a generic concept that has some analogy in node.js. I/O streams are regularly used in node.js, but I don't think they're a direct analogy to those channels. There are lots of different ways to implement non-blocking I/O. node.js itself uses several different mechanisms internally for different types of I/O. — jfriend00, May 08 '18 at 18:23

jfriend00 · Accepted Answer · 2018-05-08T18:13:55.353

It's not clear what you mean by "channels" as that is not a built-in node.js concept or a term that is used internally to describe how node.js works. The tutorial you reference in your comment is talking about the Java language, not the Javascript language so it has absolutely nothing to do with node.js. The concept of "channels" in that tutorial is something that that specific NIO library implements in Java.

But, if you're really just asking how async operations work in node.js, I can explain that generaly concept.

node.js works off an event queue. The node.js interpreter grabs the next event in the event queue and executes it (typically that involves calling a callback function). That callback function runs (single threaded) until it returns. When it returns, the node.js interpreter then looks in the event queue for the next event. If there are any, it grabs that next event and calls the callback associated with it. If there are not events currently in the event queue, then it waits for an event to be put in the event queue (with nothing to do expect perhaps runs some garbage collection).

Now, when you runs some sort of asynchronous operation in your Javascript (such as a DB query), you can your db query function, that initiates the query (by sending the query off to the database) and then immediately returns. This allows your piece of Javascript that started that query to then return and give control back to node.js.

Meanwhile, some native code is managing the connection to your database. When the response comes back from the database, an event is added to the internal node.js event queue.

Whenever the node.js interpreter has finished running other Javascript, it looks in the event queue and pulls out the next event and calls the callback associated with that. In that way, your DB query result gets processed by your code. In all cases here, an asynchronous operation has some sort of callback associated with it that the interpreter can call when it finds the event in the event queue.

Being single thread it stores the data in channels(if I am not wrong).

node.js doesn't have a "channels" concept so I'm not sure what you meant by that.

Or it executes the queued operation at the end of the program.

When the result comes back from the database, some native code managing that will insert an event into the node.js event queue. The Javascript interpreter will service that event, then next time it gets back to the event loop (other Javascript has finished running and it's time to check for the next event to process).

It's important to understand that initiating an asynchronous operation is non-blocking so you get this:

console.log("1");
callSomeAsyncFunction(someData, (err, data) => {
    // this callback gets called later when the async operation finishes
    // and node.js gets a chance to process the event that was put
    // in the event queue by the code that managed the async operation
    console.log("2");
});

// right here there is nothing else to do so the interpreter returns back
// to the system, allowing it to process other events
console.log("3");

Because of the non-blocking nature of things, this will log:

1
3
2

Some other references on the topic:

How does JavaScript handle AJAX responses in the background?

Where is the node.js event queue?

Understanding Call backs

Why does a while loop block the node event loop?

@Duck_dragon - No. Call stack is very different. The event queue is a literal queue of events waiting to call their callback. — jfriend00, May 08 '18 at 18:07
@Duck_dragon - Updated my answer with a little info about the specific library/tutorial you referenced. — jfriend00, May 08 '18 at 18:16
I will definitely look at the resources you provided. thanks. By event queue to do mean task queue from where the event look checks if the call satck is empty and then it puts from the event queue to the call stack for execution. — , May 08 '18 at 18:17
@Duck_dragon - A call stack is used to track function calls and manage function returns. When the callback from an event is done running, the last function `return` will return back to the event loop sub-system that originally called at. At the point the call stack is now empty and the system knows that previous event is done executing and node.js can then fetch the next event and call its callback. There's no "checking to see if the call stack is empty". When an event callback returns back to the event sub-system, the call stack is empty by definition at that point. — jfriend00, May 08 '18 at 18:20

score 0 · Answer 2 · answered May 08 '18 at 18:16

0

Node internally uses the underlying operating systems non-blocking io API-s. See overlapped io, WSAEventSelect for Windows, select for Linux.

answered May 08 '18 at 18:16

Tamas Hegedus

28,755
12
63
97

How non-blocking I/O works with channels

2 Answers2