 How do you guys feel about Friday? Good? All right. Me too. Okay. So today we're going to start talking about operating system content, which is pretty exciting since that's what the course is about. We will talk about sort of the top level abstraction that operating systems provide, which is a process. For some of you guys, I think you probably know a little bit about what we're going to cover for maybe the next week or so. And I apologize for that in advance if you guys are slightly bored. What's happened? So it's kind of interesting. When I was your age, back in many, many eons ago, real programmers wrote low level code. C was an okay language back then to actually write real programs in because there wasn't much out there that was better. And so to some degree, when you write code in low level languages like C or to some degree C++ maybe, you become a little bit more familiar with some of the abstractions and the functionality that's provided by the operating system. But again, time goes by. Things have improved. The world has become a better place in many ways. And one of the ways that it has become a better place is that you guys have access to new programming languages that are way better than the ones that we used to use. And those programming languages frequently hide a lot of this from you, which is again a good thing. So in order to talk about what the operating system does and how it accomplishes it, we have to sort of start by talking about what the operating system is because that's not something that you guys are always completely aware of. Where again, just by programming 10 years ago, 15 years ago, 20 years ago, you would have known a lot of this stuff. But now you don't. And to some degree, that's a good thing. Okay. So just a couple announcements before we get started. Thanks for taking the preterm. Thanks. You know, useful data for us. I think we did a reasonably good job of setting up the room. The TAs made a few mistakes, which we will correct by midterm time. But that's how we, that will be the exactly same way that we will do the midterm. So you guys know what to expect. Let's see. Yeah. So hopefully everybody is getting emails. If you're enrolled in the class, you should be automatically added to this email list. If you don't like being on the email list, you can leave the email list and then you will be automatically added again. So don't. Because this is how I reach people who are enrolled in the class. So if you are enrolled in the class and at some point you realize that you're not receiving these emails, please let me know. Because when I send email to this list, I assume that people who are enrolled in the class will get it. If you're auditing or you're just a visitor or something and you want to be on the email list, you can visit this URL and sign up. I think everybody's been getting these. Obviously the website is still not up. But I'm hoping to finish that over the weekend. At least to have assignment zero out. So sorry about that. We will start recitations and office hours next week. So if you have not yet completed the doodle poll which you received over this email list, please do it if you care. If you don't care, we're going to have a lot of office hours. So it's likely that regardless of when we schedule them, you will be able to make them. But I think by the end of today, Ali is going to close down the poll. I think it's about 40 or 50 people that have done it already. We're going to take those results and we're going to figure out how to schedule the office hours. And by Monday, we will have a plan. But again, if you care, go and complete the poll. Otherwise on Monday we will have all the office hours up on a Google calendar, which I'll share with you. And that's what we'll do for the rest of the semester. So the androp deadline is on Monday. So again, I'm going to do my best today and tomorrow to get the stuff up on the website. So you guys, if you're unsure about whether or not you're ready for the class or whether or not you want to take it right now, you can make that decision. I think it's a lot better if you make it now than having to resign in a couple weeks. But anyway, so please, if you have questions, email me, look at the stuff once we get it up online and just be cognizant of the state. Okay, one last announcement, which is that if you are looking for a partner for the class, which as I pointed out is pretty important, what we'll do is why don't we meet briefly back in Davis Hall after class today. So if you have time and you are looking for a partner, we'll do a little sort of unassigned student meet and greet speed dating type thing in Davis Hall sort of outside my office right after class. So if you're again, if you're looking for a partner, please come if you can. Otherwise, you'll have other chances to find one, but you do need one and you will want one very soon. Okay, so just a couple of notes about office hours when they start next week. So we're going to use sort of my office and the area outside of it in Davis as the place where office hours for this class are held. You should feel very fortunate that you don't have to compete for 20 square feet with every other class at UBCSE that are jammed into that tiny little terrible office. So and usually kind of we spill out to the hallway and stuff like that. So when you guys start coming to office hours, please be respectful of the course staff. Okay, a lot of that you're going to see a lot of the TAs and the ninjas around that general area because a lot of them work in my group and so that's sort of their office. So when they are on the clock, when they are supposed to be at office hours, you can bother them mercilessly. That's their job and you should not feel bad about coming to office hours and talking to the TAs or the ninjas. That's what they're there to do and we hope we will get you guys in there, especially at the beginning of the semester. There's nobody there. It's very sad. So if you want to get a good head start and you want a lot of individual attention, I would suggest you start coming next week because you will be one of the very few. Outside of office hours, please leave them alone, right? Particularly my research assistants, they have other things to do. And I don't want you guys to kind of, this has happened in the past where someone like Jinghao is obviously incredibly skilled and awesome at the stuff and so people just see him there and they're like, ooh, there he is. I'm going to go ask him a question about OS. Don't do that if he's not supposed to be doing office hours because, again, he has lots of other things to do and I kind of rely on him to do some of those other things as well. So, okay, last little bit of course, I'm going to distribute. So one thing I do is I call on people in class. I guess this is called cold calling because I don't ask you to raise your hand, whatever. So this is not something, last year I had a little tool that was integrated with the slides where your name would pop up and a picture of you. I might do that again. I felt a little awkward using that, honestly, because it was sort of like, there's always a little surprise to me who would be there. So I may do that again or I may just point at people. This is kind of a big room. So I may walk around and just put my hands on your shoulders. The annoyed one. You are supposed to answer this question. So this is not designed to make you feel uncomfortable. I promise I will be nice about it. If you don't know, just say I don't know. The point of doing this is obvious. If I ask people to raise their hands, there's about five people that will do it every time, and then about 50 people who would do it once in a while. And the rest of you guys are on Instagram or whatever. So this is designed to get around that uncomfortable fact. OK, any questions about sort of administrative stuff? I apologize, again, for the fact that the website isn't quite ready, but it will be soon. We're making good progress on it, at least getting you to the point where you guys can get started. Any questions? Yeah? Yeah, it's at opsglass.org. And you guys should be able to find your way from the home page to the things that you need. Yeah, absolutely. Good question. I'll send out the link in. I'll be so proud when we're done. I'm definitely going to send out the link to the course email list. So don't worry. You'll find it. All right, any other questions? OK, so today, my goal is to set the stage here and talk about what an operating system does. We talked last time on Monday a little bit about the two things that an operating system was designed to do. One is to provide useful abstractions, and the other is to multiplex resources, to divide resources between multiple users on the same machine. Today, we're going to probably talk a little bit more about the abstraction side of things, because we're talking about the sort of core abstraction that's at the root of what an operating system is designed to do. But abstractions in general, I feel that how many people feel like they have a real firm grip of what an abstraction is, what abstraction is in computer science? How many people talk about abstractions or think about abstractions when they're doing things? How many people have been taught about it? Has anyone ever used the word abstraction in a computer science class that you've been in? OK, that's good. So abstractions are designed to indicate that there's something different between the view of the world that's provided by something and reality. And abstractions are created to make usually, hopefully, bad abstractions can make the view of the world worse. But normal abstractions are designed to make the view that you get better. And they do that by hiding undesirable properties, adding new capabilities, and organizing information. And when we look at some of the key services that the operating system provides, we're going to see these three things being done. All right, so this is like, now I'm like Vanna White. So this is, can anyone complete the puzzle here? So the operating system abstractions, anyone who's done programming on a system, what does the operating system provide? The operating system is a program. The magic resource is on the system. But from the perspective of applications, how do they interact with it? An interface, right? So abstractions provide an interface. To some degree, abstractions are encapsulated by an interface. That's what defines them, is the interface an abstraction provides. And this is a split that we're going to talk about over and over in this class. So the key goal of an abstraction and a particular concern of operating systems is what's called separating policy from mechanism. How many people have heard about that before? They've got to let me start teaching intro courses. OK, policy and mechanism. So policy is defined by what the interface commits to doing. Mechanism is how that gets done. So someone give me an example of a split between policy and mechanism that you guys are probably pretty familiar with. Give me any example of a split between policy and mechanism. What's that? Contracts. So that's a great point, which is that an interface is a type of a contract. An interface is a way that a particular software component commits and defines what it's going to do. An interface defines a contract between the client and whatever's providing the interface. But give me an example of a split between policy and mechanism. RFCs. OK, so that's a great point. I mean, how many people are familiar with RFCs? So a lot of the internet is documented in these documents, which have this fantastic name called Request for Comments. So it turned out that in the early days when the people were designing the internet, the internet was essentially designed largely by graduate students. And apparently, they kept thinking that some group of, I don't know, faculty or leaders or managers or the people who were in charge would show up and be like, no, no, no, we're in charge now. But that never happened. So in order to sort of make what they were doing sound as kind as possible, they documented things in these things that are called Request for Comments. It's very like, hi, I have an idea about how to do something. Would you like to tell me why it's not good? But it turns out that there's thousands of RFCs now, and these RFCs docking at the core protocols of the internet. But that's a great point, which is that RFCs essentially set out policy. An RFC frequently will, now there are plenty of RFCs that contain implementation and mechanism details. But a lot of times RFCs will say, here's how something is going to work. You get to go out and figure out how it works. But let me give you a great example of this. So sorting. How many people have ever sorted something using a computer? Hopefully everybody, right? Do you know how that worked? Do you know exactly what sorting algorithm was used by the sort function that you called? I don't, right? I just call sort. And then I assume that it's going to be sorted. So this is very simple, right? This is not a difficult interface. But the policy here is that whatever I pass to you, the list or whatever, should get sorted. The mechanism is whatever algorithm that particular component uses to sort things. And the great thing about this split is that you don't have to care about the mechanism. I don't know whether you use bubble sort, merge sort, split sort, new fancy sort I've never heard of, whatever. I don't care. All I know is that when that function returns, the list is sorted. And the nice thing about this, which you may have just realized, is that because I don't know how the list was sorted, that can change. Or it could be different on different systems. So I call sort on system A, and it uses bubble sort. I call sort on system B, and it uses merge sort. By the way, these may be terrible sorting algorithms. I know nothing about sorting, right? I am not ready to teach the algorithms class. I don't know what the right sorting algorithm is to use, but the point is that it could vary. And actually, if I call sort today and sort tomorrow, the system could use different algorithms. And it doesn't even have to tell me about it. So a well-defined interface that does a good job of splitting policy for mechanism allows the mechanism to change. And we're going to see this again and again when we talk about operating systems where certain interfaces have been reused over and over again in different contexts, with slightly different twists on them. But there was enough of similarity before and after that allowed me to sort of reuse the same idea, the same interface. OK. So let's talk about a specific abstraction that is very natural to operating systems. This is a particularly useful feature of your computer, which is this idea of a file. Now, you may think of a file as something tangible. A file is something you could touch, reach out and grab. It's not quite the case. So if you know anything about how files work, what are some undesirable properties that files are designed to hide? Yeah, I mean like, well, OK. So one thing that one and undesirable property is that disks are really slow. And file systems use the file abstraction to hide a lot of that slowness from you. If your computer actually had to read and write data every time you asked it to file to an actual disk, you would be sad. You'd be a little happier now because flash drives are faster than the old ones you had. But you'd still be pretty sad. Another undesirable property is that it turns out that the storage on your computer is actually all over the place. Files end up sort of all over the disk. How many people have ever run the windows to fragger? Why? That's amazing. It's sad to me that there's more people that have run the windows to fragger than know some of the other things I've asked. Why do you guys do that? Is it because it's fun to watch? Like all the colors? It just makes you feel clean when it's over. Like all the yellow is all over there and the orange is all over there. And that's how my disk should be. It should be color segregated. Anyway, I have no idea what the windows to fragger does, but I don't run it. And disks can fail. So this is another undesirable property that my files might want to hide. What's an example of a new capability that the file abstraction provides that underlying disks don't have? Yeah, your files can have a name. Your disk knows nothing about names. Your disk knows numbers. It says Sector254, like yes, operating system, I will give the data in Sector254. It doesn't know that that's funnycatpick.jpg or whatever. It doesn't know that. It doesn't care. And also growth and shrinking. So files can grow despite the fact that on disk that growth isn't contiguous because that would be a nightmare. And there's also extra information. So we talked about abstractions is doing three things. Hiding under several properties, adding new capabilities, and organizing information. And so with the disk, with files, files also allow me to add metadata to them that, again, is not really, the disk doesn't know anything about ownership or what the permissions are. These are illusions that are created by the abstraction that are useful. They're created because they're useful when we access and manage files. Same with all these timestamps that are associated with files. That turns out to be pretty important for building a lot of other primitives. So throughout the class, I talked on Monday about how there are three main units in the class. And those three units are really focused on three main abstractions. So there are threads, which are abstractions that are designed to deal with the, and each one of these maps down to some hardware component. So threads map down to a CPU or a CPU core. Address spaces map down to memory. Files map down to the disk. Those are essentially kind of the three canonical components. I don't talk much about the network here, but there's a whole nother semester's worth of stuff about how to do this with the network. And there are certainly plenty of abstractions in the networking space as well. And you can take Demetrius' course and learn all about them. OK, I just said this. Great. So we're going to come back to this. But to start, we're going to talk about processes. So to some degree, I shouldn't say to some degree. I mean, operating systems exist. Remember, operating system is a computer program. It exists to allow other computer programs to safely share the same machine. That's why an operating system exists. How many people, I'm going to show my age here, how many people have ever used a computer that's old enough that it doesn't really have an operating system? Like old Apple II computers. There was no operating system. So if you turned on that computer without a disk in it, it would just kind of sit there, blinking at you. Nothing would happen. There was no operating system on it. The way that you use that computer, I should bring one of these in. Oh, I have fond memories of those. The way you use this computer is you've got your disk out. So now it would be like, oh, I'm going to double click on this game. No, no, no. You don't get to do that. You have to find the disk with the game on it. To put it in the drive, you have to boot up the computer. Then all the computer does is play that game, because that's all it knows how to do. There's no operating system to manage multiple processes. There's one process. That game owns the whole machine. When you're done playing that game, let's say you want to switch over and play another game. Or let's imagine, just for the sake of this, that this actually has a network. And let's say you want to check your email. You know what you do? Turn off the computer. Find the disk with your email client on it. Put that disk in the disk drive. Turn the computer back on. Check your email. Turn it off again, and go back to the game. So there are plenty of old computers that worked exactly this way. And I don't think we would have ever been able to live with those computers very much longer if we hadn't figured out that it would be more efficient and a lot more effective if we actually allowed them to do more than one thing. So operating systems exist to do this. And the process of abstraction is how that's accomplished. Yeah? Yeah, right. You can catch a lot of the computers you know, this is a disk drive, this is a keyboard, this is a monitor, this is a tape drive, catch that, even though it's a small amount of information, be considered an operating system to some extent. Yeah, so that's a great point. So what's your name? Ron. So what Ron's pointing out is that all of those programs, every program that I used on that computer needed certain common features and had to, for example, understand how to deal with the keyboard. And those features pulled together do represent, to some degree, an operating system. There's a term now that people use for this, and I'll make a note to come back to this later in the class when we talk about operating system structure, but this is sometimes referred to as a library operating system. So it's not quite an operating system that it doesn't enable multiprocessing, which is kind of the thing that makes them interesting, but it does, as you're pointing out, wrap and encapsulate a lot of useful features. So for example, every game that wanted to run on my old Apple II didn't have to figure out how to use the keyboard from scratch. It would grab a piece of software and use that as part of its binary. Does that make sense? Does that answer your question? Yeah, it's a great point. OK, so, and processes are really designed to get us from this world where the disk was its own program, and the way I switched between them was by turning the machine on and off, and where there's a manager. There's one program, and this is the operating system that's in charge, of managing a number of different things that the computer is, quote, unquote, doing at, quote, unquote, the same time. Maybe doing shouldn't be in quotes. No scare quotes for doing, but at the same time. And this is sometimes true and sometimes not. You guys are very familiar with the concept of a process. Pretty much everything you use on your computer is a process, is an application. If you use a smartphone, those are apps. Each app is a separate process. And well, I mean, I don't know. I don't know how many processes anybody uses anymore. I use one process, which is Chrome. That's it. And again, we'll come back to that later, because that's an interesting story about how that world is changing. But to the degree you use multiple things like Skype, iTunes, whatever, those are processes that are being managed by the operating system. So one of the things the operating system is trying to do is to give each process the illusion that it has access to the entire machine. I don't want to hide features of the machine from that process. Now, this conflicts with my desire to make sure this happens safely, so I need to do both. But to some degree, each process is given a view of the machine where it has access to the CPU. It has access to memory. It has access to storage. And so processes can be seen as a container in which I put other abstractions. So a process has one or more threads. It has an address space, which is my abstraction for managing memory, which we'll talk about in great detail. And it has access to files and other things. Man, this is what happens every year. I have to realize that the slides want to follow along. Keep hitting the button. OK, so one of the most important tasks of the operating system is to isolate processes from each other. And this is one of the key ways that the operating system safely multiplexes resources. Multiplexing resources is not supposed to be done at the cost of breaking applications or causing them to crash and stuff like that, unless your window is 95 or whatever, in which case that's fine. And the general rule of thumb is simple. Inside a process, anything goes. So when Firefox starts up, the system says to it, here Firefox, here's these resources that you might need. And Firefox can pretty much do whatever it wants in its own little private universe. But Firefox should not be able to crash other processes, cause the system to crash, hog system resources, et cetera. Now Firefox may be buggy and crash itself. That's certainly possible. That's not the operating system's problem. Yeah. Have you ever been to Lebson? I've ever been to Lebson. Does Firefox there crash other things? Oh, nice. OK, yeah. So that's a feature. Interesting. So that's not supposed to happen, right? This particular task was something that it took some operating systems a long time to get right. And whatever was running in Baldy 21, it doesn't fall into that category yet. Are those machines running like Windows ME or something? Oh, interesting. That's very curious. But in general, this is the operating system's goal. Isolate processes from each other. And the result of this is that if a process wants to communicate internally, so clearly a lot of what processes do, a lot of what your web browser does, requires internal communication within the process itself. That I want to make as easy as possible. But if two separate processes on the system want to communicate with each other, that there's a lot more rules. Because that has to be done safely so that the two processes can interfere with each other, right? So the first is intra-process communication, which is a word that I never use again. The second is what's called inter-process communication or IPC, and that's something we'll talk about a little bit more today. So again, within your own process, within your own little container, you can do what you want. You can share memory between threads. You can allocate and de-allocate stuff. That's not a problem. And there's a lot of different ways for processes to communicate internally. Now, that doesn't mean that it's going to be easy. So one way to do this is using shared memory. I can also, all the threads within a process also share file handles. We'll come back to talking about this. And there's a small amount of information within these processes that's typically private, but even that isn't actually private. So within your own process, if one thread wants to share its own memory that it's using for a stack with some other thread, you can do that. That's not typically regarded as an extremely good idea, but it is possible. And this requires signalization mechanisms in order to get this to work. And this is something that we will talk about a lot. Because to some degree, the operating system, like I said, is on some level a big, multi-threaded process. And it needs to get this type of sharing right. And a lot of what you guys do this semester on the assignments will be dealing with this sort of thing. How do I share data and other things between multiple threads running within the same process? The process being the operating system. Yeah? The same friends were operating. Scalable to virtual. Yeah? Kind of. Yeah, so that's a great point. What's her name? Ben. So what Ben is pointing out is, OK, let me have some fun. So let me go back here. And we'll talk about isolating processes as a protection boundary. OK, so yeah, let's fast forward. And now let's say it's 2016. So I can take this slide. And through just a couple of simple VIM search and replaces, I can make this a slide about virtualization. Because what I can say is, in virtualization, the idea is that the hypervisor, which is the new operating system, is responsible for isolating multiple operating systems from each other that are running on the same machine. So this may blow your mind a little bit. But how many people have ever used EC2 for anything? Please go use it. It's free. Come on, guys. You can set up a free EC2 instance. It's fun. Go play on Amazon's cloud. So those little machines that Amazon sets up for you, they don't map down to a piece, a little computer in some room somewhere. That's, oh, that's mine. No way. Your machine is sharing a server with a bunch of other machines. And to some degree, yeah, you can take this up just a whole other level. Does that make sense? Yeah, we'll come back and talk about that when we talk about virtualization. But a lot of the ideas about operating system isolation apply pretty much the same to isolating multiple different operating systems from each other. It's just a little bit more of a blow your mind type of thing. OK, so an IPC. So now communication between processes is a variety of different ways to do this. And all of these require some degree of coordination between the processes that are using them. The reason is I need to make sure that I do this without either process crashing itself or crashing the other process. And again, these all require cooperation between the two processes. So if you're a process on a typical computer and you don't want anyone else to bother you, that's supposed to be OK. Now, I don't know what's going on with Firefox and Eclipse and Baldy21. But normally, if I'm a little process and I just want to mind my own business, I don't want anyone to bother me, no one should be able to bother me. No one should be able to send me things I don't want or change my memory or whatever. That's just not supposed to be able to happen. And a lot of these semantics are layered on top of traditional Unix permission mechanisms. So for example, if you log on to Timberleague, you just can't start killing stuff. That would be interesting if you could. And a lot of what you guys read about in terms of root exploits and other things are essentially people using various holes in the operating system to gain access to types of things that they should not be able to do. Usually, people that get root on a machine don't go around killing stuff. They just read your private email and do all sorts of other fun things. Killing stuff is too obvious. But anyway, so I shouldn't just be able to kill off or interrupt any other process on the machine. OK, so now I've got some little shell examples. When we guys get you set up with your vagrant VM this weekend, you guys will be able to look at some of these and sort of run them yourself. How many people are extremely comfortable using the Unix shell? OK, hopefully by the end of the semester, everybody's handle the alpha extremely high. I actually think that typing speed is correlated with success in this class. I hate to say that, but that's kind of true. OK, so here we are. So what have I done here? I ran a little command. So this is one example of IPC. One tiny little bit of inter-process communication is that when I create a new process and that process exits, that process gets to tell me one thing. And that one thing is an integer that tells me something about what happened. Now clearly, that something is pretty limited. It's limited to usually there's a set of error codes that the process will throw. What's the traditional semantics for Unix processes? If they succeed, they return what? Zero. Zero is the special value that means there was no error. If they return non-zero, that typically means something went wrong. And then what you need to do is get out the man page and look up three, because three tells you something, maybe, if it's a well-designed program, about what went wrong or what happened. So here what I did is I fired off bin true. Does anyone know what bin true does? Bin true. Bin true, yeah? Returns zero. Returns true, zero. So bin true is a fun little program to run. It doesn't do anything, it just returns. So imagine I've got my main statement, return zero. That's it. So all it does is return success. So what I did is I had the shell sleep and run this in the background. And then I waited for it using this command. So these are such a bash commands. What this says is tell the shell to wait for process 5817. That's its process ID. And then when it's done, it tells me that it finished. Now when a normal process exits in bash, it doesn't tell you if the exit code is zero, because it figures everything's OK. Down here you'll see I ran bin false. What does bin false do? Returns one, which is bad. And so the shell tells me, by the way, that thing that you told me to wait for, it exited with code one, meaning maybe something went wrong, of course, but it's bin false. And so bin false is supposed to do that. So this is, as you can see, the most limited and simplest version of IPC. All I get to do is pass one int back and forth. We just say this, right? And yeah, so if you use bash and you've ever run something and you want to know what happened to it, you can run this command. So bin false will just return. But if I tell bash to echo this, it'll tell me the error code of the thing that just ran. So that can be handy if you forgot to capture it in some other way. All right, so another building block of IPC are what is called pipes. How many people have used pipes before? Everybody has programmed this. This is like the way that you program UNIX systems, right? This is kind of like the UNIX programming model from the command line, is I run a bunch of little programs that each do one specific thing, and I build more complicated things by allowing them to pass the output to the next program. So here's what I did here. I'm essentially looking for all of the programs that I own. This is a little bit of a hacky way to do it, but it works. And so this command lists all the programs on the system, and this next command figures out which ones have me somewhere, right? So you can see that this includes processes that are owned by me. This is my SSHD session, and that it also includes processes that just have me in the name, right? So this is, I think this is SSHD. That's its process that's supporting my SSH session, right? Okay, so, and pipes are actually something that's created by and operated. This is part of the operating system interface. It allows me to create a buffer between two processes. And it essentially allows the output from one process to be passed to another process without the processes knowing anything about it. They don't really have to be told that this is happening. So for example, this command grep, it's used to reading input. Normally if you run grep, it reads from standard input, but in this case, because I set up a pipe in the shell, it's getting its input from the output of the PS. And the operating system is in charge of sort of queuing data in between these processes and making sure that the data is passed appropriately. All right, yeah, so on some level, you can think of systems programming from the shell as just a series of tubes, right, a series of pipes. Okay, so, signals. How many people have ever used a signal on, wow man, this is awesome. This is a larger number of people that have done this stuff from last year, so that's great. Signals allow me to send, and to some degree, signals are almost like an analog of return codes. One int that comes back, signals, it's the opposite. I get to send a command like a little piece of data, it's just a number, to a process. Now remember what I said before, which is that processes can feel free to ignore this information. There is nothing that requires a process to handle a signal, except for one special one, which isn't handled by the process at all. So if in general, if there's a process running on the system and you start sending into a bunch of random signals, it's just gonna be like, I don't know what you're trying to say to me, I'm just not gonna do anything, right? So if a process hasn't registered a handler for a signal, nothing happens, okay? So here's what I did, I ran this long sleep command, and then I killed it in the foreground. A lot, you guys send signals a lot, you just don't realize it. What is a typical way of sending a signal to a process that you guys may or may not realize is done this way? Close the window, okay, so actually that's a good point. How many people have had this annoying experience where they start up some GUI command from a shell and they close the shell and the window closes? That's because a signal is being sent from the shell to that thing that you started from it, right? That signal turns out to be called SIG child. It means that the parent has exited. Now some GUI applications don't close, and that's because they choose to ignore it, right? Some decide that they're gonna shut down. But there's one that's way more common, I heard somebody say it. Control C, so it turns out when you guys hit Control C, didn't you ever wonder how that worked? Yeah, what Control C does is Bash sends a SIG term signal to the current running process. That's how Control C is implemented. Has anyone ever tried to Control C something that didn't work? Yeah, so it turns out that processes aren't required to handle Control C. If they just wanna sit there and be like, no, I'm not gonna stop, that's cool. It turns out that if you write a C program, by default it's set up to handle Control C by calling exit. So you don't have to do anything to get Control C to work. But if you want to write a nasty little UNIX program that you can't Control C, it's very easy to do. Now because of that, so you may be wondering, well how do I kill off that process that won't handle Control C? There's a special signal that has the number nine, or it's also referred to as SIG kill. Control C is not SIG kill. Control C is SIG term, right? Control C is terminate. Kill is much more violent, right? So kill is actually not handled by the program. It's handled by the operating system and there is no way to ignore it. So when you kill SIG kill something, it will turn, like the operating system will terminate that process. It doesn't even ask the process to handle it. It just says you're done. So if you ever have something that you can't Control C, you can background it in the shell and then kill it off using SIG kill, right? So that's what I did here. All right, I just set this, okay, yeah. Yeah, this is probably my favorite XKCD cartoon of all time, right? And just to point out, a lot of times you can't send, so SIG kill, again, like no stopping SIG kill, not something that you could ascend to random processes. But by all means, you know, and I make it trouble for saying this, log into Timberlake and just try it, right? Like see if it, because if it works, there's something wrong, right? Like you can write a little script that just walks through the entire process table and tries to SIG kill everything and see what happens, right? Hopefully the department website doesn't go down. Well, I don't know. There's worse things in the department website point. All right, so we're gonna come back to IPC. Return codes are something that you guys are gonna have to implement for assignment two. They're pass through exit. Pipes we'll talk about again when we talk about fork, since pipes have this intricate little dance with fork that allows you to set up shell pipelines, like we talked about before. Signals is not something that we're gonna talk about a lot in this class. Signal handling is something that's a little tricky to get right, particularly on processes that have multiple threats because it turns out that the signal can be delivered to any of them and that can make things a little bit tricky. Sheridan memory is an IPC mechanism. We'll certainly talk about a lot more when we talk about address spaces in VM. Okay, any questions at this point? It's sort of a whirlwind tour of IPC, yeah. So this is how much of the stuff that we're talking about is more kernel based versus opera? Ooh, good question. Okay, so kernel versus opera system, maybe that's what I should address. So, this isn't, so to some degree the opera system and the kernel are pretty much synonymous, right? If you want to kind of strengthen your definition of kernel, what I would say is the kernel is the part of the operating system that is not optional because when we talk later in the class, we'll talk about one of the ways that opera systems are extensible which is through the use of shared modules. So for example, if you run Windows or Linux or whatever, that opera system doesn't automatically load when it boots every possible piece of software it could ever need because that would be huge. It would take up all of your memory, right? And it doesn't need to because you have one kind of keyboard and you have one kind of mouse or whatever. But I would say the kernel is the part that's not optional, right? So the system call interface on Unix is in the kernel, right? That is not something that you can unload, right? That is pretty much like the key interface that the OS provides, right? So all this stuff, all these IPC mechanisms, really most of them utilize the system call interface, right? Files, no, files are a little different. You could argue maybe file systems aren't in the kernel, I don't really know. Usually the kernel needs a file system to run, right? But what kind of file system is something that's a little more flexible? So it's a good question. Did I answer your question? Okay, good. Any other questions before we go on? Okay. So before we start talking particularly about the CPU, I just want to clear up one potential source of confusion, which is that between a process and a threat. So I've been talking about processes today and what I've been talking about is a process. Now, today on all modern operating systems, there is a distinction between a process, which is this container that we've been talking about that can communicate with other processes and represents one thing that one application is doing and a threat of execution within that process. So almost every single thing that you run that's useful other than the shell, other than the shell. Although, I don't know. Maybe there are like multi-threaded versions of bash out there that are doing weird things in the background. I don't think so, though. Most of the stuff you guys run, web browsers, iTunes, whatever, all that stuff has multiple threads, okay? Now the reason that's a little confusing is because we can talk about both a process and a threat as running, right? We talk about a process is running when one of its threads is executed. We talk about a threat is running is when that particular threat is executed. All right, and the other way to remember this is that a threat of execution is really tied to the state required by a single CPU, right? Where a process includes these other things. And threads belong to a specific process, right? Linux makes this even weirder because Linux calls these all tasks. And it turns out on Linux the distinction between a process and a thread is made by whether or not that task is part of another task. Right, in which case it's part. All right, does this make sense? Hopefully this is not too confusing. And hopefully I won't slip up and switch these up very much. And again, Linux uses tasks, but it's really the same idea. Okay, so let's talk a little bit about a typical process and how it's using the underlying system resources. So I just pointed out something like Firefox will have multiple threads of execution that are running. What are those threads doing? So typically you're gonna have Firefox to have, actually if you look at Firefox, it has a gazillion threads, right? Why? What are those threads? Why does Firefox need to have so many things running at once? Yeah, yeah, sure. So there's probably a thread that's in charge of handling input. Yeah, there are these little popups that it has like the download manager. So if you start downloading something, it probably forks off a thread to handle that download, but what else? Yeah. Okay, so there may be a little bit. I think someone said another source of threads. Tabs, right. Tabs, multiple, yeah. Yeah, so, well, and I am in different protocols, right? So it turns out when you download it, when you load a webpage, Firefox use, sorry, I wanna start talking more about Chrome. I've been a Chrome user for a couple of years. These slides are kind of old. Everyone was making fun of me for using Firefox, so I switched. Anyway, so Chrome is going to use, when you go get a webpage, Chrome doesn't use one thread to get the webpage. It's way too slow. That webpage has all these different pieces that need to be fetched from all over the place. So it turns out that Chrome uses a bunch of different threads in parallel just to get the stuff from the webpage, much less render it, right? So the rendering is probably also gonna be done in a concurrent way. But just the resources that I need to load one webpage, I mean, have you guys ever seen how many connections or how many different objects are required to like load the New York Times homepage? It's mind boggling, right? There's like 50 different images that come from 50 different places, right? All sorts of different things, style sheets or whatever. So to make that fast, Chrome uses a bunch of different threads. So even one page load is not single thread. You would be sad if it was single thread because it would be slow. You should try it sometime. There's probably a way to get Chrome to use one thread for a page and then you can see how much slower it is. Okay, so, but I think we got to all this. So interface events, rendering the screen, loading the parts of the webpage in parallel so it's a lot faster. What does Firefox use memory for? Yeah? Cookies? Ooh, cookies. Cookies are probably on disk, right? Because they're persistent, right? What's that? Yeah, just like the rendered content, right? I mean, you know, it's taking all this structured data and it's producing pixels. And so a lot of that rendering and those resources end up in memory because that's fast, right? It's falling in the back. Yeah, well, that's a good question. Yeah, it might cache a little bit of the pages for forward and back navigation. I don't know if that's safe or not, but that's an interesting idea. And of course, you guys forgot one thing. Chrome.exe, right? The actual program, like the program that's running is loaded in memory. That's where the instructions are coming from, right? We got a lot of this stuff. Let's just get through this example and we'll pick up on Monday. What does Firefox use files for? Somebody pointed at cookies, which is a good one. Probably has configuration files. What else? What else makes your web browser faster? Yeah. What's that? I don't, plug-ins make it slower. No, plug-ins make it slower. False. What makes it faster? What do, what do, the cache? Yeah, I mean, web browsers cache all sorts of stuff. That way, when you go back to the website, they don't have to load it from the website. It's already on disk, right? Bonds, stuff like this. Okay, so we'll pick up here on Monday. Keep an eye on your email this weekend for updates from us and have a great weekend. I'll see you on Monday.