Node.js callback function question.

Asked 2 years ago, Updated 2 years ago, 38 views

When I ran the code below, I thought that Enter loop at the beginning was printed, and then setTimeout said to run it 1 second later Time out, 4 seconds after this is printed, exit loop. I think it should be printed in this order The actual order of action is Enter loop followed by Exit loop followed by timeoutranat~. Shouldn't it be printed before exit loop because Timeoutran is in the order of 1 second?

// set function to be called after 1 second

setTimeout(function() {
    console.log('Timeout ran at ' + new Date().toTimeString());
}, 1000);

// // store the start time

var start = new Date();
console.log('Enter loop at: '+ start.toTimeString());
// // run a loop for 4 seconds
var loop = 0;
var end = start.getTime() + 4000;

    while( Date.now() < end) {
    loop++;
}

console.log('Exit loop at: ‘ + new Date().toTimeString() +
'. '. Ran ‘ + loop +' iterations.'); 

node.js

2022-09-21 19:44

1 Answers

You need to know how nodes work It's understandable.

SetTimeout is spinning the Timer on another thread and then generates an event at the time you specify (1 second in the above example) to deliver an asynchronous callback to the event loop.

The callback that outputs Timeoutran at...

If so, it should run 1 second after 'Enter loop at:...' is output, so why doesn't it work like that way? And why is the order of output that looks like that?

There are two reasons for this.

The main thread of the node is a single thread. That means that you have to wait for your turn for the other tasks before you finish the series of instructions that you wrote earlier.

In the example above, the while statement is increasing the loop variable value for 4 seconds. Until this repeat is over, the codes written below cannot be executed and are waiting endlessly for their turn. The timeout callback, which is counted asynchronously and is supposed to run after 1 second, also has to wait another 3 seconds for its turn due to the code flow. There's a series of things going on, so there's no room for intervention. Eventually, the output of 'Timeoutran at...' which was pushed back after a total of 4 seconds, was 'Exit loop at:...'' and at the same time.

It's hard to print it out all at once. Let's say I understand because of the above situation. So why does the 'Timeoutran at...' print out later?

After completing the I/O operation on the node, registering for the asynchronous operation is an event callback. I/O asynchronous operations (such as setTimeout) run in parallel on other threads and register their callbacks in the Event Queue when completed. The jobs waiting for this queue are checked by the Event Loop to see if the main thread is idle, and if you are resting, take it out one by one and run it.

To verify that the main thread is idle, check that the Call Stack is empty. Call Stack is stacked in function calls.

(Coughing) That's how it works.)

The full code in the example above runs directly on the global context. This is also a function call. That's why it's registered with the Call Stack. Let's call it main().

This main() function is the last part of the function to output 'Exit loop at:'. It must run to this last line before it disappears from the Call Stack. Because of 'Exit loop at: ...Until ' is printed, Event Loop determines that the main thread is still working. So the work in Queue is delayed.

4 seconds after the main function is executed, 'Exit loop at:...'' The moment of this printout has arrived. That means that the main() function has come to an end. In Call Stack, the main() function disappears. Only then did the Call Stack completely empty. Event Loop doesn't leave it alone because the main thread is playing. So, they throw the task that was pushed into the Event Queue to the main thread to execute it. This is a callback that outputs a 'Timeoutran at...' that has been waiting for 3 seconds because the main thread is busy.

So in the end...

'Enter loop at: ...'

'Exit loop at: ...‘

'Timeout ran at ...'

It is printed in order.

It's not intuitive until you understand the principles of motion In this way, nodes have become single thread and concurrency programming languages.

That's why I feel like I'm fast at working alone. In fact, V8's performance is fast. :)

This is the answer I wrote before. https://hashcode.co.kr/questions/6621/indexjs-%EC%95%88%EC%97%90-%EC%A0%81%EC%9D%80-%EC%BD%94%EB%93%9C%EB%93%A4%EC%9D%80-event-loop%EA%B0%80-%EB%8F%8C%EA%B8%B0-%EC%A0%84%EC%97%90-%EC%8B%A4%ED%96%89%EB%90%A9%EB%8B%88%EA%B9%8C

Besides this, there are many more accurate and good explanations when you google it. It'll help if you look it up.


2022-09-21 19:44

If you have any answers or tips


© 2024 OneMinuteCode. All rights reserved.