JavaScript Event Loop


Published on

Published in: Technology
  • Be the first to comment

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide
  • Old school colloquialism, ya dig it?
  • Why I’m credible (OR AM I?!)
  • Explain multithreaded, how it is the true way to to do concurrent programming, and the best way to make use of systems with multiple cores (which is pretty much every system these days), but also allude to the difficulty of doing so.
  • Describe how it is definitely not multithreaded, has downfalls of not making use of multiple CPUs, but kinda appears to be concurrent, and that it is easier to implement technologically.
  • If you run the code: function a(x) { b(x+1); } function b(y) { alert(y); } a(12); Those all get added as “frames” within the current stack. Once you do something with a callback that gets executed after I/O happens, or a DOM event, that code is actually added to the Queue. When the current stack is complete it grabs the next item in the queue (if it’s ready). The heap doesn’t really matter, it’s just where the browser throws stuff in RAM.
  • Run the code on the left (either in Node or your browser) and you’ll see the code on the right. The setTimeout automatically adds the execution to the next queue. The a() b() function calls are added to the stack since they’re running right now. Notice how the order isn’t exactly what you would expect. The setTimeout(), if this were a MultiThreaded application, would likely run immediately some of the times and maybe half way through execution other times.
  • I mention PHP/MySQL a lot since I used it for several years, but the same applies to most single core languages. Basically, your app is almost always waiting on other shit to happen, unless you’re crunching a ton of numbers. Web apps are all I/O bound! Grab this remote RSS feed, talk to a database, send an email, you name it. The math parts and concatenating strings are super fast. The graph on the right shows just how intense this is.
  • I adapted this diagram from a CodeSchool tutorial, it does a great job showing how stuff executes seemingly in parallel. Since I/O isn’t CPU bound, it can be done at the same time. The Sequential I/O section represents a PHP or Ruby or any other traditionally built application. The Parallel I/O section represents an application that is either MultiThreaded or using an EventLoop with non blocking I/O.
  • You can implement event loops in other languages, but it won’t be pretty since you’ll need to use some specific syntax for registering callbacks. JS is cool though because this is built in, it’s just how it works, it feels au naturale. Maybe mention Node.js using LibUV, which relies on lower level utilities to tell it when to “wake” up.
  • Here’s an Apples to Oranges comparison of EventLoops. Both of these examples were taken from their respective homepages (slightly tweaked for verbiage). I don’t know Ruby at all, and I honestly don’t know if these do the same things. This is just meant to show that most languages can implement an EventLoop, even when it’s not built in. The Ruby code is a little more terse, since it’s not “native”. You also have to be careful when building scripts this way, as the libraries you use should have non-blocking I/O.
  • A race condition is when two bits of code running on different CPUs write to the same memory at the same moment. Who wins? If X = 10; thread 1 tries to add 2 to it, and thread 2 tries to add 3 to it, simultaneously, the value will become 12 or 13, not 15. Stateful apps in PHP requires the use of Memcache or a database. Node.js can simply use local variables. Parallel cURL requests can be done with a complex library, but in Node.js one can simply use callbacks.
  • Mention the cons of single threaded event loops (as well as ways to fix it since I’m biased). Multi-node can spin up several processes for handling HTTP traffic, you prolly want to set it to the number of CPUs you have. Memory leaks can happen since your app is always running. PHP runs for a moment and then dies, Node.js can run for weeks. Perhaps mention ways to mitigate issues.
  • Browser support looks pretty good, feel free to use it today. Node.js doesn’t have the Worker() object available, but there are plenty of alternatives.
  • Not sure if this slide should stay, it duplicates information from one and two slides previous.
  • JavaScript Event Loop

    1. 1. JavaScript Event LoopNot yo mama’s multithreaded
    2. 2. Who is Thomas Hunter?• Web developer for 8+ years• Dow, Ford, Quicken, Startup, Barracuda• Started development with PHP & MySQL• Became a Node.js fanboy• Writing a book on Backbone.js for Packt• @tlhunter |
    3. 3. What does MultiThreaded mean?• Makes use of separate CPU Cores as “Threads”• Uses a single process within the Operating System• True concurrency• Can have Race Conditions (simultaneous memory use)• “Hard” to get it right• Ran out of Ghz, hardware adds more cores
    4. 4. JavaScript is SingleThreaded• Makes use of a single CPU core• CPU intensive work is never “concurrent”• Easier to pull off, as in less technical difficulties
    5. 5. Technical Implementation• Stack:• Functions to run and available variables• More added as code is run• Stuff guaranteed to run in order• Heap:• “Chaotic” listing of objects• Queue:• Gets added to stack when stack empty• setTimeout and setInterval added hereCredit: Mozilla Developer Network
    6. 6. Example Code-runconsole.log("Adding code to the queue");setTimeout(function() { // Added somewhere in Heapconsole.log("Running next code from queue");}, 0);function a(x) { // Added somewhere in Heapconsole.log("a() frame added to stack");b(x);console.log("a() frame removed from stack");}function b(y) { // Added somewhere in Heapconsole.log("b() frame added to stack");console.log("Value passed in is " + y);console.log("b() frame removed from stack");}console.log("Starting work for this stack");a(42);console.log("Ending work for this stack");Adding code to the queueStarting work for this stacka() frame added to stackb()frame added to stackValue passed in is 42b() frameremoved from stacka() frame removed fromstackEnding work for this stackRunning next codefrom queue
    7. 7. Your App is Mostly Asleep• Node.js:All I/O is non-blocking• E.g. it gets thrown into the Queue• Browser:Wait for a click to happen• PHP:Wait for a MySQL query to run• These show how slow I/O can be →L1-Cache 3 cyclesL2-Cache14 cyclesRAM 250cyclesDisk 41,000,000Network 240,000,000
    8. 8. Sequential vs Parallel• Traditional web apps perform each I/O Sequentially• With an Event Loop, they can be run in Parallel• Since most time is wasted doing I/O, very inefficient
    9. 9. Non JS Event Loops• Event Loops can be implemented in other languages• However, JavaScript was built this way, feels “natural”• Examples:• Ruby: EventMachine• Python:Twisted & Tornado• PHP: ReactPHP
    10. 10. !JS Event Loop Examplesrequire eventmachinemodule Echodef post_initputs "Someone Connected"enddef receive_data datasend_data "#{data}"close_connection if data =~ /quit/ {EventMachine.start_server "", 8081, Echo}var net = require(net);var server = net.createServer(function (socket) {console.log(Someone Connected);socket.pipe(socket);});server.listen(1337,;EventMachine in Ruby Node.js
    11. 11. Event Loops are Awesome!• No race conditions• Typical web apps spend their time waiting on I/O• No funky syntax; it just works• Perform I/O operations “in parallel” easily• Stateful web applications are easy compared to PHP• Long run apps, don’t need web servers, shared data...
    12. 12. Event Loops aren’t Awesome!• CPU intensive work will block your process• You can offload work to different processes (Node.js)• It isn’t making use of those 8 cores you’ve got• You can use the Multi-node module though (Node.js)• Memory leaks are possible, not so with PHP• You can program better and prevent it though ;-)
    13. 13. Web Workers• You can use MultiThreaded JavaScript in your browser• IE10, Firefox 3.5, Chrome 4, Safari 4, Opera 10.6• var worker = new Worker(task.js);• Use Message Passing to share data• You share simple JSON data, not complex objects• Prevents deadlocks/race conditions because of this
    14. 14. Conclusion• Great for I/O bound applications (most web apps)• Horrible for CPU bound applications (do it in C ;)• Appears to be a single multi-threaded process• “Fakes” concurrency• @tlhunter