Threads, Processes, Asynchrony and JavaScript
Going into phase 4 of the Flatiron Coding Bootcamp, the process of going from “I don’t know what I don’t know” to “I know what I don’t know” is increasingly.. humbling every single day. As a person who genuinely enjoys the process of learning though, it’s also exciting. A good example of that is threads in programming. Now that me and my cohort members are more than halfway through our program, this concept of threads doesn’t just keep abstractly popping up, it’s a core part of our education. However, the thing about a bootcamp is that it’s hard to dig into some of these more nebulous concepts and I realized one day relatively recently, I don’t really know what the hell a thread is. SO, as is wont to happen to new programmers, I fell down a Google rabbit hole and found some interesting information.
Let’s take it from the top!
It’s hard to talk about threads without first getting acquainted with CPU. Without getting too too dry, the CPU(Central Processing Unit) is the core of every computer. It’s what makes your computer, your phone, your Xbox, or anything technological in your house right now operate. Most, if not all, processors these days have the ability to run two tasks at a time(thanks to multi and hyper-threading)by creating an extra virtual core. What that amounts to is that your quad core processor on your laptop roughly has a doubling affect. If you’re on a more Mac, you most likely have a 1:1 physical to virtual CPU ratio.
Each core can only one run thread at a time.
If we take a look at our Activity Monitor, we can break down all of this gibberish even further! In the bottom right hand corner of our handy lil picture we see threads and processes. Threads are small bits of a process, which is the execution of a program.
So let’s say it’s Friday, I’m feeling good after getting out of class and I boot up Spotify for my new Release Radar playlist(side note: TOKiMONSTA just re-released the instrumental version of her album and I highly recommend if you’re into electronic background music.); my computer executes the process to start and run the Spotify program. As I continue interacting in the Spotify program, it will continue to execute the process needed to run it. When a process is executed, it’s assigned to a specific physical and virtual place in memory on the computer. Processes don’t interact with each other because they can be complex and sometimes a lil’ messy. Their isolation of execution is the reason why when Spotify has a meltdown and freezes, I can Force Quit the application and it doesn’t also mess up what happens with Google Chrome or Slack.
That brings us to threads!!!!
Processes are run with threads, and a process can be single or multi-threaded. As depicted above, a thread (the squiggly) has access to a lot of data inside the process(the entire blue box). If every program was single-threaded, that would mean I would only be able to run one thread at a time and it would only run on one of my eight cores. That leaves a lot of room to gallop with just a wee bit of horsepower! With multi-threading, now processes can execute many tasks at the same time, which also allows these threads to share and exchange information. Now, a single program can run multiple threads to allow faster and more dynamic usability!
All of this finally brings me to JavaScript. If you’re still reading, we’re about to go full nerd, so be prepared.
Back in our third phase of Flatiron we learned that JavaScript was a single-threaded scripting language. It has a single call-stack and memory heap(in the process). How can that possibly be efficient? Well the cool thing about JavaScript is that when you’re looking at a webpage, you don’t need multiple threads for one page, especially with asynchronous events.
History time.
Modern web-browsers had to make a choice of how to handle the overwhelming amount of information multiple tabs can have. We’ve all been there, had way more tabs than we should have open, couldn’t find where the music was playing, and all of a sudden the app crashed! Many web browsers were (and still are) thread-based, meaning each tab was treated as an individual thread. The objective was to allow tabs the ability to share information and operate under one process for the sake of saving on memory, but that’s why if something isn’t loading or taking too long on tab 5, you have to force close all 30 tabs.
Chrome’s workaround was to make each tab its own process. While the upfront memory storage was costly, in the long run it allowed Chrome to more easily compartmentalize data crashes. Remember, since processes don’t share info, now you can kill a single webpage and keep your browser running. (Granted, this isn’t foolproof.)
JavaScript works as a single-threaded language because it only occupies CPU with each page that is currently being viewed. And with asynchrony, there’s no need for multithreading. You render a view page first, load up your call stack with asynchronous events, and as information is needed, it’s loaded and rendered to the page one piece of data at a time. Then when the user gets bored of Facebook and opens Reddit, the process is started over again on a single render thread on that single page. It’s magic!
I know this was a lot. If you’ve read this far, you’re a trooper and I appreciate you. I am by no means an expert on this stuff, but threads are probably the most fascinating part of computer programming I’ve found yet and I encourage anyone reading to do their own research. Without multi and hyper-threading, we wouldn’t have the expedient and seamless computer processes we have today.
