Jobs

As of ES6, there’s a new concept layered on top of the event loop queue, called the “Job queue.” The most likely exposure you’ll have to it is with the asynchronous behavior of Promises (see Chapter 3).

Unfortunately, at the moment it’s a mechanism without an exposed API, and thus demonstrating it is a bit more convoluted. So we’re going to have to just describe it conceptually, such that when we discuss async behavior with Promises in Chapter 3, you’ll understand how those actions are being scheduled and processed.

So, the best way to think about this that I’ve found is that the “Job queue” is a queue hanging off the end of every tick in the event loop queue. Certain async-implied actions that may occur during a tick of the event loop will not cause a whole new event to be added to the event loop queue, but will instead add an item (aka Job) to the end of the current tick’s Job queue.

It’s kinda like saying, “oh, here’s this other thing I need to do later, but make sure it happens right away before anything else can happen.”

Or, to use a metaphor: the event loop queue is like an amusement park ride, where once you finish the ride, you have to go to the back of the line to ride again. But the Job queue is like finishing the ride, but then cutting in line and getting right back on.

A Job can also cause more Jobs to be added to the end of the same queue. So, it’s theoretically possible that a Job “loop” (a Job that keeps adding another Job, etc.) could spin indefinitely, thus starving the program of the ability to move on to the next event loop tick. This would conceptually be almost the same as just expressing a long-running or infinite loop (like while (true) ..) in your code.

Jobs are kind of like the spirit of the setTimeout(..0) hack, but implemented in such a way as to have a much more well-defined and guaranteed ordering: later, but as soon as possible.

Let’s imagine an API for scheduling Jobs (directly, without hacks), and call it schedule(..). Consider:

console.log( "A" );
setTimeout( function(){
    console.log( "B" );
}, 0 );
// theoretical "Job API"
schedule( function(){
    console.log( "C" );
    schedule( function(){
        console.log( "D" );
    } );
} );

You might expect this to print out A B C D, but instead it would print out A C D B, because the Jobs happen at the end of the current event loop tick, and the timer fires to schedule for the next event loop tick (if available!).

In Chapter 3, we’ll see that the asynchronous behavior of Promises is based on Jobs, so it’s important to keep clear how that relates to event loop behavior.