脚本和setTimeout / setInterval如何在NodeJS中一起工作？

Question

Reading through the NodeJS Event Loop description I wonder how setTimeout and setInterval can actually work.

The page says NodeJS first runs the given script (let REPL alone for now) and then enters the event loop. But what if I call setTimeout in that script and expect it to trigger while the script is still running? Isn't that the normal case actually? According to the description the timer callback will not be triggered before the main script ends, which sounds really weird to me.

For those interested, here's the NodeJS outer even loop (there are actually 2 nested loops): https://github.com/nodejs/node/blob/master/src/node.cc#L4526

Answer 1

let's do this by example

setTimeout(function(){
    print('there');
});

print('hi');

this will print hi then there

here's what happen

the script will be proccessed until last line and when ever it finds a timer function it will add it to a queue which will be handled later at the end of the execution by the queue scheduler

loop queue => [ setTimeout ]

before exit there should be a scheduler, some kind of a loop to check if we have something in the queue and handle them, then once queue is out of all timers the loop will exit.

let's suppose we call setTimeout inside setInterval

setInterval(function(){
    setTimeout(function(){
        print('hi')
    }, 500);
}, 1000);

loop queue => [ setInterval ]

after 1000 ms

setInterval will be fired and the inner setTimeout will be added to the queue

loop queue => [ setTimeout, setInterval ]

now we get back to the main loop which will wait for another 500 ms an fire the inner setTimeout function, then remove it from the queue because setTimeout should be run once.

loop queue => [ setInterval ]

back to the main loop, we still have items in the queue, so it will wait another 500 ms and fire again ( 500 + 500 = 1000 ms) the inner setTimeout function will be added to the queue again

loop queue => [ setTimeout, setInterval ]

back to the main queue agin and again ...

Now this is simply how timers work, they are not meant to handle blocking code, it's a way to run code at some intervals

setInterval(function(){
    // do something long running here
    while (1) {}
    setTimeout(function(){
        print('hi')
    }, 500);
}, 1000);

main loop will block here and the inner timeout will not be added to the queue, so this is a bad idea

nodejs and event loop in general are good with network operations because they don't block when used with select for example.

setInterval(function(){
    // check if socket has something
    if (socketHasData( socket )){
        processSocketData( socket );
    }

    // do something else that does not block
    // maybe schedule another timer here
    print('hello');
}, 1000);

libuv which is the event loop used in nodejs, uses threads to handle some blocking operations like IO operations, open/read/write files

Answer 2

[EDIT] humm re-reading your initial post, I think I know what bugs you. You mentioned nodejs in your post, implying you might be coding a server.

If you are not really familiar with server side JavaScript and more used to php server for example it might be very confusing indeed.

With a php server, a request creates a new thread that will handle it and when the main script (as you call it) ends, then the thread is killed and nothing else runs on the server (except for the webserver that listens to request, like nginx or apache ).

With nodejs, it's different. The main thread is alone and always running . So when a request arrives, callbacks are fired but they are still in that single thread. Said otherwise: the main script never ends (except when you kill it or that your server crashes :) )

---

Well, that is accurate. Because of the single-threaded nature of JavaScript, if a timer ends while the main thread is busy, the timer's callback will wait .

When you do

setTimeout(callback, 1000)

You are not saying "I want this callback to be called in exactly 1s" but actually "I want this callback to be called in, at least, 1s"

This article by John Resig is an excellent read and goes through the details of the JavaScript's timers https://johnresig.com/blog/how-javascript-timers-work/

Answer 3

But what if I call setTimeout in that script and expect it to trigger while the script is still running?

You don't expect that. You expect your synchronous code run to completion way before the timeout occurs.

If the script is still running, because it's doing something blocking - it hangs - then the timeout callback doesn't get a chance to execute, it will wait. That's exactly why we need to write non-blocking code.

Isn't that the normal case actually?

No. Most of the time no JS is executing, the event loop is idling (while there might be background tasks doing the heavy lifting).

Answer 4

Given that Node is single threaded, it (v8 engine) always executes the current script before moving on to the next one. So when we start a node server with a main script, it loads, parses, compiles and executes that script first, before it runs anything else. Only if the current running script hits an I/O call it gets bumped out to the back of the event loop, giving other scripts or setTimeout callbacks a chance to execute. This is the very nature of JavaScript engine and the reason Node is not considered good for long running, in-memory CPU intensive tasks.

As @atomrc said in his answer, setTimeout and setInterval are just a hint to node to run the callbacks after the timeout period, there are no guarantees.