4

I am studying about the event loop provided by libuv in Node. I came across the following blog by Deepal Jayasekara and also saw the explanations of Bert Belder and Daniel Khan on youtube.

There is one point that I am not clear with- As per my understanding, the event loop processes all the items of one phase before moving on to another. So if that is the case, I should be able to block the event loop if the setTimeout phase is constantly getting callbacks added to it.

However, when I tried to replicate that- it doesn't happen. The following is the code:

var http = require('http');

http.createServer(function (req, res) {
  res.writeHead(200, {'Content-Type': 'text/plain'});
  res.write('Hello World!');
  console.log("Response sent");
  res.end();
}).listen(8081);


setInterval(() => {
  console.log("Entering for loop");
// Long running loop that allows more callbacks to get added to the setTimeout phase before this callback's processing completes
 for (let i = 0; i < 7777777777; i++); 
 console.log("Exiting for loop");
}, 0);

The event loop seems to run in a round robin fashion. It first executes the callbacks that were added before i send a request to the server, then processes the request and then continues with the callbacks. It feels like a single queue is running. From the little that I understood, there isn't a single queue and all the expired timer callbacks should get executed first before moving to the next phase. Hence the above snippet should not be able to return the Hello World response.

What could be the possible explanation for this? Thanks.

Shubham Dixit
  • 9,242
  • 4
  • 27
  • 46
user2549980
  • 593
  • 7
  • 20
  • FYI, timers are managed completely differently than other types of callbacks. The timer system is a specific part of the event loop itself. – jfriend00 Mar 05 '20 at 04:47
  • 1
    This article will probably help: [Understanding the Node.js event loop phases and how it executes the JavaScript code](https://dev.to/lunaticmonk/understanding-the-node-js-event-loop-phases-and-how-it-executes-the-javascript-code-1j9), particularly the description of the "poll" phase. – jfriend00 Mar 05 '20 at 04:50
  • @jfriend00 The event loop waits at the poll phase until an expired timer callback is added to the timers queue/heap. But once it starts processing the timer callbacks it will exhaust the whole queue, and since i keep adding to it the loop should get stuck. Unless... the callbacks that are added to the queue after the event loop starts processing it are not considered until the next iteration. Then I suppose it would make sense. Or if http.get() method uses promises or nextTick internally. I'll research more into this. Would love to hear your opinions. – user2549980 Mar 06 '20 at 05:00
  • I don't think timers get added to the queue when they expire. instead, when it's in the event loop nodejs checks to see which timer's time has passed. This would allow them to only process timers that have fired at the start of this event loop cycle, thus making the scheduling more fair. If you want the real details here, you'll have to go look at the libuv code for this part of the event loop. – jfriend00 Mar 06 '20 at 05:03
  • OK, I dug into the libuv code, found the event loop code, found the timer processing code and posted an answer explaining it. – jfriend00 Mar 06 '20 at 06:27
  • @jfriend00.Thanks for sharing such an incredible article :) – Shubham Dixit Mar 06 '20 at 06:32

2 Answers2

5

If you look in libuv itself, you find that the operative part of running timers in the event loop is the function uv_run_timers(). 

void uv__run_timers(uv_loop_t* loop) {
  struct heap_node* heap_node;
  uv_timer_t* handle;

  for (;;) {
    heap_node = heap_min(timer_heap(loop));
    if (heap_node == NULL)
      break;

    handle = container_of(heap_node, uv_timer_t, heap_node);
    if (handle->timeout > loop->time)
      break;

    uv_timer_stop(handle);
    uv_timer_again(handle);
    handle->timer_cb(handle);
  }
}

The way it works is the event loop sets a time mark at the current time and then it processes all timers that are due by that time one after another without updating the loop time. So, this will fire all the timers that are already past their time, but won't fire any new timers that come due while it's processing the ones that were already due.

This leads to a bit fairer scheduling as it runs all timers that are due, then goes and runs the rest of the types of events in the event loop, then comes back to do any more timers that are due again. This will NOT process any timers that are not due at the start of this event loop cycle, but come due while it's processing other timers. Thus, you see the behavior you asked about.

The above function is called from the main part of the event loop with this code:

int uv_run(uv_loop_t *loop, uv_run_mode mode) {
  DWORD timeout;
  int r;
  int ran_pending;

  r = uv__loop_alive(loop);
  if (!r)
    uv_update_time(loop);

  while (r != 0 && loop->stop_flag == 0) {
    uv_update_time(loop);                    <==  establish loop time
    uv__run_timers(loop);                    <==  process only timers due by that loop time

    ran_pending = uv_process_reqs(loop);
    uv_idle_invoke(loop);
    uv_prepare_invoke(loop);

 .... more code here

}

Note the call to uv_update_time(loop) right before calling uv__run_timers(). That sets the timer that uv__run_timers() references. Here's the code for uv_update_time():

void uv_update_time(uv_loop_t* loop) {
  uint64_t new_time = uv__hrtime(1000);
  assert(new_time >= loop->time);
  loop->time = new_time;
}
jfriend00
  • 683,504
  • 96
  • 985
  • 979
0

from the docs,

when the event loop enters a given phase, it will perform any operations specific to that phase, then execute callbacks in that phase's queue until the queue has been exhausted or the maximum number of callbacks has executed. When the queue has been exhausted or the callback limit is reached, the event loop will move to the next phase, and so on.

Also from the docs,

When delay is larger than 2147483647 or less than 1, the delay will be set to 1

Now, when when you run your snippet following things happen,

  1. script execution begins and callbacks are registered to specific phases. Also, as the docs suggests the setInterval delay is implicitly converted to 1 sec.
  2. After 1 sec, your setInterval callback will be executed, it will block eventloop until all iterations and completed. Meanwhile, eventloop will not be notified of any incoming request atleast until loop terminates.
  3. Once, all iterations are completed, and there is a timeout of 1 sec, the poll phase will execute your HTTP request callback, if any.
  4. back to step 2.
laxman
  • 1,781
  • 4
  • 14
  • 32