JavaScript has a concurrency model based on an , which is responsible for executing the code, collecting and processing events, and executing queued sub-tasks. This model is quite different from models in other languages like C and Java. event loop Runtime concepts The following sections explain a theoretical model. Modern JavaScript engines implement and heavily optimize the described semantics. Visual representation Stack Function calls form a stack of . frames { a = a + b + } { y = foo(x * y)
} .log(bar( )) ( ) function foo b let 10 return 11 ( ) function bar x let 3 return console 7 //returns 42 When calling , a first frame is created containing arguments and local variables. When calls , a second frame is created and pushed on top of the first one containing 's arguments and local variables. When foo returns, the top frame element is popped out of the stack (leaving only 's call frame). When returns, the stack is empty. bar bar's bar foo foo bar bar Heap Objects are allocated in a heap which is just a name to denote a large (mostly unstructured) region of memory. A JavaScript runtime uses a message queue, which is a list of messages to be processed. Each message has an associated function which gets called in order to handle the message. Queue At some point during the , the runtime starts handling the messages on the queue, starting with the oldest one. To do so, the message is removed from the queue and its corresponding function is called with the message as an input parameter. As always, calling a function creates a new stack frame for that function's use. event loop The processing of functions continues until the stack is once again empty. Then, the event loop will process the next message in the queue (if there is one). Event loop The got its name because of how it's usually implemented, which usually resembles: event loop (queue.waitForMessage()) {
  queue.processNextMessage()
} while waits synchronously for a message to arrive (if one is not already available and waiting to be handled). queue.waitForMessage() Each message is processed completely before any other message is processed. "Run-to-completion" This offers some nice properties when reasoning about your program, including the fact that whenever a function runs, it cannot be pre-empted and will run entirely before any other code runs (and can modify data the function manipulates). This differs from C, for instance, where if a function runs in a thread, it may be stopped at any point by the runtime system to run some other code in another thread. A downside of this model is that if a message takes too long to complete, the web application is unable to process user interactions like click or scroll. The browser mitigates this with the "a script is taking too long to run" dialog. A good practice to follow is to make message processing short and if possible cut down one message into several messages. In web browsers, messages are added anytime an event occurs and there is an event listener attached to it. If there is no listener, the event is lost. So a click on an element with a click event handler will add a message — likewise with any other event. Adding messages The function is called with 2 arguments: a message to add to the queue, and a time value (optional; defaults to ). The represents the (minimum) delay after which the message will actually be pushed into the queue. If there is no other message in the queue, and the stack is empty, the message is processed right after the delay. However, if there are messages, the message will have to wait for other messages to be processed. For this reason, the second argument indicates a time—not a time. Here is an example that demonstrates this concept ( does not run immediately after its timer expires): setTimeout 0 time value setTimeout minimum guaranteed setTimeout s = ().getSeconds();

setTimeout( { .log( + ( ().getSeconds() - s) + );
}, ) ( ) { ( ().getSeconds() - s >= ) { .log( ) ;
  }
} const new Date ( ) function // prints out "2", meaning that the callback is not called immediately after 500 milliseconds. console "Ran after " new Date " seconds" 500 while true if new Date 2 console "Good, looped for 2 seconds" break Zero delay doesn't actually mean the call back will fire-off after zero milliseconds. Calling with a delay of (zero) milliseconds doesn't execute the callback function after the given interval. Zero delays setTimeout 0 The execution depends on the number of waiting tasks in the queue. In the example below, the message will be written to the console before the message in the callback gets processed, because the delay is the time required for the runtime to process the request (not a time). ''this is just a message'' minimum guaranteed Basically, the needs to wait for all the code for queued messages to complete even though you specified a particular time limit for your . setTimeout setTimeout ( { .log( );

  setTimeout( { .log( );
  }); .log( );

  setTimeout( { .log( );
  }, ); .log( );

})(); ( ) function console 'this is the start' ( ) function cb console 'Callback 1: this is a msg from call back' // has a default time value of 0 console 'this is just a message' ( ) function cb1 console 'Callback 2: this is a msg from call back' 0 console 'this is the end' // "this is the start" // "this is just a message" // "this is the end" // "Callback 1: this is a msg from call back" // "Callback 2: this is a msg from call back" A web worker or a cross-origin has its own stack, heap, and message queue. Two distinct runtimes can only communicate through sending messages via the method. This method adds a message to the other runtime if the latter listens to message events. Several runtimes communicating together iframe postMessage Never blocking A very interesting property of the event loop model is that JavaScript, unlike a lot of other languages, never blocks. Handling I/O is typically performed via events and callbacks, so when the application is waiting for an query to return or an request to return, it can still process other things like user input. IndexedDB XHR Legacy exceptions exist like or synchronous XHR, but it is considered a good practice to avoid them. Beware: (but are usually implementation bugs, rather than anything else). alert exceptions to the exception do exist Specifications HTML Living Standard. The definition of 'Event loops' in that specification. Node.js Event Loop Credits Source: https://developer.mozilla.org/en-US/docs/Web/JavaScript/EventLoop Published under license Open CC Attribution ShareAlike 3.0

Mozilla

JavaScript Concurrency Models: The Event Loop

About Author

Comments

TOPICS

THIS ARTICLE WAS FEATURED IN

Related Stories

A Quick Introduction to the Resize Observer API

The Essential Guide to Relearning Java Thread Primitives

A Guide to Improving Your Python Performance Speed

A simple introduction to Python’s asyncio

Assume It Worked and Fix Later

Async/Await in Golang: An Introductory Guide

A Quick Introduction to the Resize Observer API

The Essential Guide to Relearning Java Thread Primitives

A Guide to Improving Your Python Performance Speed

A simple introduction to Python’s asyncio

Assume It Worked and Fix Later

Async/Await in Golang: An Introductory Guide

Light-Mode

Classic

Newspaper

Minty

Dark-Mode

Neon Noir

Minty

HN StartUps