Morning Keynote- Everything You Need to Know About Node.js Event Loop - Bert Belder, IBM

Morning Keynote- Everything You Need to Know About Node.js Event Loop – Bert Belder, IBM



good morning uh who you more huh I can I can speak Dutch Dale good all right well for people that don't know me you're not supposed to know me anyway my name is indeed Berg Baldur and this is my limit of history with no gesso I got involved in 2010 in 2011 we started working on libuv which is the internal like event loop and IO abstraction library in this talk I'm gonna like mash that all together and pretend it's like one thing in 2013 we I was one of the founders of strong loop probably the least important one I need to be honest about that but and but you might know it from like cool stuff like loop back and then in 2015 that got acquired by IBM and so now I'm here in my blue t-shirt and this also responds were taught by the way so you know tune in to your subconsciousness for you know invisible instances of product placement and like things you really do not want to know do you know that does anyone here has like the someone on the Internet's wrong syndrome sometimes so like this usually when you do it keynote you have to talk about like the community and like where it's very important by the way but and like you know where's the project heading like in the grand scheme of things but this is not this talk this is just purely a technical talk and the reason is that if sometimes I entered this in the you know you want to make it talk to yourself and you enter no Jesse venting for some sort of diagram and every time I cringe because like these are all wrong I'm sorry like if you made one of these I'll buy your beer afterwards but like no no no so like for example do does like networking happening and happen in the threat pool no not really no and the event queue is not another thing what was this slide again oh yes the event loop returns stuff to decline no it does not there's no non-blocking worker thread pool now-now-now or you know a stack of events you know you know stack is a data structure and you take you know put stuff on top and you take them top first no it's not a thing but the photo by the way is it's Trevor Norris I did not want to implicate him he's an awesome ctc member it was just a coincident this is a this one's kind of good it I have some you find this on Stack Overflow it's probably the best one that you can find on the internet but still I do not agree with the way process the next stick is added to this slide okay so first before I get started with like I showing how you how it should be represented I need to share some dirty secret with you so we're kind of used to well if you're not doing no js' and like asynchronous i/o you've ended programming you're kind of used to writing code like this right like you say connect and write and read and you make you give commands to your operating system and will do stuff for you and you know you said what you want it will give you the result back and you know for a you know the new person it might seem that your computer is actually working really hard when you're doing this when you're you know sending data to the network it might be you know busy with it but really that's total like somewhere in the in the early 90s every computer learned a trick called direct memory access and that meant that you know whenever your CPU fetches your program runs on your CPU right I wanted to do something with you know hard disk or network card it would just send a command to some peripheral device and the peripheral device would kind of figure it out with the memory and so your CPU could just easily do something else in the meantime because it didn't have to constantly work to push data to it to their devices and then what happens when the device is done or it needs more data or whatever it will send an interrupt to your CPU and it's called interrupt through a reason like CPUs have a very you know questionable attention span because at the moment that happens it will just instantly jump and you know go handle that interrupt and kind of forget where it was in the first place it's kind of an issue it's very hard to program computers like that if you you know have done some microcontroller programming I'd have to do that yourself it's really not easy to get right so it's kind of understandable that people came up this because of just you know if you're not very smart like me this is just way easier oh yeah so this is the this is the dirty secret your operating system takes care of like that the total lie that you're dealing with anyway I know Jess we you know we have an event loop and that means that we can do asynchronous programming but we don't have to you know deal with the like a DeeDee kind of a processor the way the processor works so this is the start this is how I would start in a diagram of an event loop you start with you know it always starts with your actual program it's not a callback it's just whatever is in index J s or whatever happens when you do NPM start and at the very end we also know there's you always get this like process exit event and and if everyone who has ever tried to use it knows that you know you can't really use it for anything because it's really the last thing that's ever going to happen and since no Jess asynchronous you know you set a timer it will never fire you right you know you try to write some data to the network it might go out but you can never tell it's really not very practical but this is sort of the beginning in the end so let's fill out the blanks there's just basically four steps that an event loop takes at every every iteration first of it is it will figure out if there were any timeout you know so I'll get into how that actually works later then there's the unicorn and unicorn I'll give you much more detail on that later but that does the most of the magic if there's any disk or network or child process activity going on in your process it will find those events there and it will maybe do some more management internally and it will call your callbacks that's the most important things think and I have all these like for Jas boxes in here because there's really no you know event loop that sends things like it's it you know your event loop just goes back and forth it you know into it goes into libya v and fingers timers and ankles your javascript and then it figures out network events and calls your javascript and then it goes on in set immediate queue so that's everything you did with set immediate and at that point it will call your callbacks and then finally there's this sort of internal phase where we create closed events and clean up open sockets and that kind of stuff and then we get a dislike nice little corner here and you know leave UV or no decides whether to keep running or go to that like infamous process exit event alright so a little bit more you know a detail here let's say your little JavaScript that run right there after figuring this set immediate callbacks you know is let's say it calls set timeout what what happens internally is we add your you know your timer we compute when you know when to set the alarm basically we add it to the timer heap this is a picture of like there's an actual timer heap somewhere in the world you're from friends you might recognize it this is at sound Lazare station and at the by the time the event loop gets to the little alarm spot it will look at the at the timer heap figure out which ones have expired and line call your callback simple enough same goes for let's say creating a server the server is not done with the thread pool it's we go directly to the operating system and ask it hey give us you know give us a notification if a new connection is made to our server and then you know when the unicorn function is trying to trying to figure out those events it will pick up the fact that there is a new connection last but not least the minions we call it workers internally worker threads there's typically four not three and you know if you do something like the file system it will get a worker it will go do it for you and then at again that the unicorn function will figure that out this also kind of explains how no just knows how either it should exit or it should just keep going because it's it simple as that you know every time we send you know we start an operation like this file stuff that we send to the worker we add add one to the reference counter and then when the call back comes when the event happens we just subtract one very simple and that means that at that like little you know split where we can either decide exit or continue we can just look if the reference counter is zero we exit otherwise we don't simple as that okay let me tell you a little bit about the Unicorn function oh this is that thing again the the code that I showed you in the beginning what stands out about these functions can act right and read is that they both do something and they get the result that means that at you know your program of course cannot keep running and what we want to do inside nodejs is kind of kick off these operations but we know it cannot because we want to do some things asynchronously we cannot have to result immediately and so what the Unicorn function must be able to do is get the get the results of like anything that was going on in the background I'm not going to go into all the details of how this works actually if you want to do that I think there's a code and learn on Saturday morning by Sawa and he will give you probably all the details and stuff you even don't want to know so this is the Unicorn function and it's all built on top of very different operating system concepts it depends on which operating system you're running on there's equal weight an equal weight will only tell you basically if there's a network socket that can be read or written to and basically everything else that we need to be able to pick up and unicorn fraction need to be shoehorned into that model so like practically speaking for example if you need to pick up an event from the thread pool is that we create a secret internal pipe and like the third probe writes at one end and then you know this equal weight function you know reads that one at the other side k event is what what happens in BS DS and and OS x kind of the same thing and then there's windows it has get queued completion status and as you can already see in the name it gives you a completion status that was somehow cute and the completion status of course the result that we were looking for and that queuing is happening actually automatically and then what I'm not saying here seeing here is there is all these unicorn functions must have a timeout so when we run them what we do is we basically compute when the next timeout you know it will happen we don't really care about the ones in the far future just the next one so we can you know say okay if nothing happens for the next ten seconds and the next time it's in the next ten seconds then it will just return with no events and that we you know the event loop will you know go back spinning and it will hit that timer place again and run your time out um there was something else I needed to say about this but I forgot that's kind of dumb alright um so if you need to make any diagrams just don't pretend everything happens in a threat well that's very painful for me because we tried very hard not to do that and also it confuses people because they're like well notice like really not like you know they say synchronous with research flat poo is just like Java that's not true what we cared about most when we made no js' is to make a very scalable server so something that could you like thousands of open connections and you can actually do that with WebSockets if you ever tried that no just doesn't break a sweat and so whenever we can we we try to use the kernel so nothing else we just ask the operating system hey gives a signal and tell the unicorn function when you know when there's when something happened but that's it's not always possible unfortunately operating systems are not very good and so files and sometimes pipes have to run in the thread pool and then there's this this is very maybe practical to know whenever you look up a domain so you say well you use a request for example you say hey get me google.com and what happens is the DNS lookup function gets called and that also runs in a thread pool and the reason for that is that the way your computer looks up DNS locates the NS records is kind of operating system specific and people are expected to accept to happen or to behave exactly the same as your browser and so we have to use the operating system there there are better DNS functions that actually actually are asynchronous but you have to call them manually and but if you ever have a performance issue I would say try to look at that the bottom two rows are not really or combs are not really that important we need to use single hand hinder sometimes signal handlers are kind of like interrupts in the in the sort of computer architecture picture it is also something that can immediately distract your program that's why nobody ever uses signal handlers for any serious programming because it's kind of impossible to get right and windows has like this weird weird concept of wait threats which means you spin up a threat to basically just wait for stuff and we needed to use it sometimes we try not to um so to complete the picture what and it stands out about this if you compare it with the earlier ones that I said were wrong is like some stuff is really not in here like event emitters are not in here and they really shouldn't be in here we also know the in here is next they can and like promise I'll resolve and the reason is that they are kind of an event loop of their own so every yellow box that you saw on this slide kind has like a little little event loop inside it and that little event loop inside it has another even smaller event loop inside it and so that means that after we call that callback that you thought was going to run node Africa is gonna check our guarantee resolve promises and it's going to keep doing that until there are no more resolved promises and then it's going to check are there more next stick events or callbacks going on in your program and it will also keep doing that until there are no more next a callback so if you remember nodejs or 10 I believe it might it would sometimes complain hey you had 10,000 that's because we were afraid you were locking up your program you know by calling next it continuously and it would never escape this like little inside loop yeah also by the way it isn't it weird sorry for that I'm kind of responsible next stick is really not the next stick it's just immediate and then said you me is not very immediate at all it's more like the next stick but whatever just remember that okay this is all I'll tweet the I'll tweet the the slides so if you ever have to write a book and need a need to like not screw up then you know look at the talk again thank you very much

Author:

13 thoughts on “Morning Keynote- Everything You Need to Know About Node.js Event Loop – Bert Belder, IBM”

  • Will Henderson says:

    At the end, Bert describes promise.resolve callbacks being executed before process.nextTick callbacks. However, I have done some (basic) testing and I believe it is actually the other way around: 1) process.nextTick callbacks, 2) resolved promises, 3) next event loop phase etc.

    Thoughts anyone?

    The script I used for basic testing is here, which I hope makes sense if your read the file description: https://github.com/14willh/node-event-loop/blob/master/nextTick-and-promises.js

    On a final note, this was a great video if you already have some sense of what the event loop is all about. Definitely helped me understand the Event Loop and how things are actually being executed.

  • He may have the knowledge on the topic, but is not very skilled in passing it on to others. At moments I was not even sure if he was trying to explain it to himself or to the audience???

  • I always had and still have the impression that most people have misconceptions about NodeJS and dont really know how it works.

  • This guy may know his stuff but he's not very good at conveying it concisely and clearly. I had to put him at 1.5x speed just to not get bored hearing his constant tangents.

  • This video should be viewed after this video https://www.youtube.com/watch?v=P9csgxBgaZ8 It was hard for me to get it first but after sam roberts explanation everything makes sense

  • harpreet singh says:

    This is it. Bert Belder kills it. I would recomend it to everyone who would like understand node event loop. Also What he represents on loop are phases of loop which are better explained in node docs guide https://nodejs.org/en/docs/guides/event-loop-timers-and-nexttick/

  • good work, but the final diagrams were not that meaningful in my opinion, if i didnt dive deep into v8 and libuv code i dont believe i'd really have a final painted picture about the event loop from this talk.

Leave a Reply

Your email address will not be published. Required fields are marked *