 I'm not going to send email. Piazza is going to be the way you're going to find out about this. OK, great. All right, so other announcements. Thank you guys for coming on Wednesday. People took the preterm. That's really useful information for us. Yeah. So I guess there's an option where I can have announcements posted on the course, like the front page for the course where the link, not the ops class or the website, but the Piazza front page. Would people find that to be helpful? Yes? OK, great. So I'll do that in the future. Would that make things easier? OK, yeah, I have the same problem. OK, so we put the office hours on the calendar. We're going to have 16 office hours per week. We have, between the course staff and the TAs, we have 47 person hours of office hours per week. So in each office hours slot, you'll find between one and four members of the course staff there to help you. And we started those this morning. I'm sorry I forgot to announce that on Piazza, but we will run them this afternoon as well. And then next week we'll be into our usual schedule for office hours. At times, we may change the staffing of office hours, particularly after exams when my TAs will have a lot of grading to do, so we might take them off of office hours and just let the ninjas do them. But that's going to be the calendar for the rest of the semester. We did our best, based on the Doodle poll, to ensure that there was at least one or two office hours that everybody in the class could attend. If there aren't, for some reason, let us know. I'm not sure exactly what we can do about it at this point. But if you did the Doodle poll and there are office hours that you can't make any of the office hours that we scheduled, please let us know. We want to make it possible for you guys to get help. Recitation start next week. The out drop deadline is Monday. There's already a certain number of people that have dropped the class, which is fine. But I would encourage you guys to get going on assignment 0 and 1, which are due two weeks from today. So please get started on those. So particularly over the weekend, if you're trying to make a decision about whether or not to stay in the class. Not next week, but the week after. I think the dates are the 11th and the 13th of February. I'm going to be out of town. The highest probability thing that will happen is that we will screen lecture videos from 2014. It was a great year. I was on the top of my game, so they're really good. And we'll just screen them in here. You guys are also welcome to watch them online or whatever you want, but one of the TAs will come in here and just put them up. And then I'll ask the TA to stick around and answer some questions afterwards. So that, as far as I know, is the only time I'll be out of town during this semester. Sorry about this. It's a trip to the West Coast, so it was pretty much impossible not to miss two classes. All right. So with office hours, what we're going to do this year, I didn't post a location on the website, but we're going to try to hold them in and around the official TA office on the second floor. Now there's one tiny little room there that every TA in the department is supposed to somehow use. And so we don't use that room. We try to spread out and get into that desk space down there. If we find ourselves, if it's crowded in there, I would also consider just moving them to the second floor lounge or somewhere where there's a bit more room. The only drawback with that room is that I've been told and I've experienced this myself that it gets really hot in there in the winter, because the sun is beating down. It's kind of stupid, right? I don't know why it gets so hot in the winter in the building in Buffalo. Anyway, so when we have office hours, OK, so we'll see how that works. So please be respectful of the TAs and ninjas. A lot of these men and women work in my lab. So you'll see them around Davis Hall. You'll see them in Davis 301B. When they're on, when they're scheduled for an office hours, they are yours. You guys are welcome to bother them. When they are not doing office hours, please let them work on other things, right? And so please, in particular, outside of office hours, unless you want to talk to me, don't come in the lab, don't just sort of show up at random times looking for help. But again, we have 16 hours a week where you guys can come get help. Outside of those times, please use the forums and other ways of getting help, right? I ask my TAs to do a lot with you guys over the semester, but I do want them to be able to do other things as well. All right, so today is the inauguration of a new little tool that I built to allow me to do cold calling in class. So this is something that I've done in the past, but in the past, it's relied on me memorizing the names of everybody in the class. And while I would like to do that by the end of the semester, I do not know your names now, right? So as a substitute for it, here's what we're going to do. Boom. Akhilesh, would you please answer the question? Is Akhilesh here? Great, there we go. So this is what's going to happen, right? At various points throughout the class, I may ask a student to answer a question. If I ask a student to answer a question, the next thing that's going to happen is you might see your name up there. It's Akhilesh here. There we go. OK, so this works. Awesome. Here are the caveats. I am not, this is not designed to make you guys feeling comfortable, right? There's sort of an association with cold calling that's done in law school in the first year, and this is why people drop out and they have mental breakdowns because they were so nervous about answering the question. No, no, no, this is not the point, right? The point is, if I ask a question in class and I don't do this, what happens is there's maybe 10% of you guys that have any idea what's going on, right? And you're thinking about the question, but the other 90% of you are like thinking about Facebook or Snapchat or whatever. And so this is designed to make sure that when I ask a question, there's this nice little moment there where you're all thinking, what's the answer, right? Because you're waiting for your face to show up right there, right? Ryan, are you here? Awesome, OK. You guys, and by the way, these guys are off the hook because you will only be called on once per class. Whoops, that's a little bug. And at some point, we'll get around to potentially being able to report absences and do attendance based on the website. We're not there yet, but we'll get there, all right? Any questions about this? All right, it's going to make things way easier on me. OK, so let's start talking about operating system abstractions, right? Last time, we talked about the two things that operating systems do. Providing abstractions was one of them. What was the other thing that operating systems are responsible for? Is all the way on Monday? No, don't bother raising your hands now because I don't need to do that. All right, Jackie. Jackie here? Yeah, OK, something about hardware. That's good. Girish? Girish here? All right. He doesn't know. Anyone want to help these guys? Now you can raise your hands. Yeah? Multiplexing hardware resources, right? So two things that operating systems do. Abstractions, multiplexing hardware resources, OK? Abstractions are designed to simplify the design of applications, right? And they do this in a couple of ways. The first way they do it is they do it by hiding undesirable properties. Another way they do it is by adding new capabilities, allowing you to do things with an underlying system that those parts of the system wouldn't allow you to do. We'll go through examples of this, right? And the other thing that abstractions tend to do is provide a way of organizing information about different parts of the system, OK? So this is like Wheel of Fortune, right? Would somebody like to solve the puzzle? I'll give you the first one. Abstractions provide an interface to application programmers that separates blank from blank. How many people have ever heard about a separation of something from something when you've been a programmer or designing systems? Maybe this is just a systems thing. Anybody want to guess? I'll just take guesses here, yeah. OK, we're close. Interface is already up here, so that's a good point, right? And interface is designed to separate the implementation from people that are using it. But a lot of times this semester we'll come back to this design principle, which is when we design computer systems and operating systems, we try to separate blank from blank. Anybody else want to solve the puzzle? Yeah. Yeah, policy for mechanism. Awesome. Policy separating policy and mechanism, right? To some degree, every interface does this, right? What the interface documents is the policy. This is what's going to happen. What the interface does not have to document is the mechanism. How is this going to take place? And we will come back to this over and over again throughout the semester, right? This is a really important part of building good interfaces. And building interfaces is a really important part of building robust computer systems. All right, so let's talk about files, right? How many people have ever recognized files as an abstraction? How many people know what a file is? OK, great. At least there's a few of you guys left, right? Most of us, it sounds like, can I open that file? How do I open that file in my web browser? So yeah, there are still these old fashioned things called files that live on some old fashioned thing called the disk, which most of you guys just ignore actively as you use the internet, including myself. Let's talk about files, right? What are some of the, so first of all, what are files abstracting? It's not a question that's up on the slide, but what are files designed to abstract? Menpreet, where is she? Is she here? She's not, OK. Mohit, yeah, doesn't know. I mean, where are files stored on the disk? So the file is the abstraction, right? Operating system abstractions always map down onto some underlying physical resource, right? In this case, the physical resource is the disk, right? The low level piece of heart, OK? So what are some undesirable properties of the disk that files might be designed to hide, right? Yeah, so for example, let's say every time you wanted to access some information stored on your computer, you needed to know the exact disk blocks, the exact locations on the disk. Like literally, you had to be able to point at the disk platters and be like, that's where my data is, right? You'd have to stop them from spinning first, because if they're spinning, it's really hard to tell where you're pointing, you know what I mean, right? So I don't know what you do with flash, right? It's like over there in that corner of the flash chip, that's where my stuff is. So, well, another thing, disks are slow, right? This is another property of computer systems that we'll come back to over and over that's driven a lot of the design amount on our operating system. So that's something I'd like to avoid, right? I don't want to access the disk every time I need some information. File is going to be a way of doing some intelligent things to make disk IO faster, right? And as the person pointed out, where your stuff is on disk, it actually turns out it's all over the place, right? How many people have ever run, does Windows still have a defrager? Has anyone ever run it? Is it, does it work? Okay, so yeah, but I mean, if you want an illustration of that, run the Windows defrager, right? And it's all these colors and things like that, and then it sits there and your computer gets really slow for a long time and the disk is, right? And then when you're done, all the parts of one color are all over together where they belong, because everyone knows all the yellow files go over there, right? And the green ones go over there, that's just how the disk works, right? Anyway, a friend of mine once wanted to write a fake Windows defrager that just made a lot of noise and spun the disk and really didn't really do anything and then see if people thought their computer was faster afterwards, right? But anyway, so you know that, you know, chunks of storage are everywhere and storage can fail, right? So files can also be used to provide redundancy and fault tolerance properties, right? Okay, what new capabilities do files have, right? What can you do to a file that would be difficult or impossible or just really ugly to do if you had to deal with the disk directly? Yeah. Editing, so yeah, with editing it's like, where was my stuff, right? I have to find it, things like that. Well, let's continue with the file, yeah. Okay, okay, we're gonna get to that, right? So yeah, but certainly I can protect, but that's a great point. I can protect things in a way that the disk doesn't know how to do, right? Hold on, boom, Daniel. Daniel here, yeah. What do you think? Okay, okay. Let's try someone else. Hongbin. Yeah, doesn't know either. How many people should I try before I give up? I don't know. All right, so we have growth and shrinking, right? So that's kind of like editing, right? I wanna add things, where am I gonna put them, right? On the disk, again, everything gets scattered around, this is the reason, right? So to some degree, some undesirable property in the disk is caused by this new capability, right? I can organize them, I can name files, right? Your disk has no idea what your files are called. None. It doesn't know anything about those file names, right? Zippo. The disk knows about a disk like most computers communicates most effectively when you talk to it in numbers, right? It knows disk block 62. It has no idea that that is in foo.mp3, right? So, and information about the file, so someone already brought this up, ownership and permissions, right? This is technically both the capability, the ability to prevent certain people from reading right in my files, and information about the file that isn't, doesn't really belong, isn't something that disk really needs to think about, right? The disk should just respond to requests, the file system and the file art is in charge of figuring out who can access certain information, right? And then there's also a lot of information about the file that file systems store in order to be able to do certain things, right? A user might wanna know when the last time they opened a file, right? File system can store this information, right? So, any questions about abstractions before we go on? Hopefully this was a useful example, okay? So, here are the abstractions we're gonna talk about, and these are their pictures, right? So, we have a thread, right? And each one of these abstractions maps directly down to a hardware resource. So, what hardware resource does the thread map down to? Thread is designed to abstract what? Yeah, yeah, the CPU, right? Address spaces, right? This one might be a little bit more tricky, right? An address space is an abstraction that's designed to abstract what? How about Kyle, no Kyle? How about, is it Elliott or Breckenridge? Breckenridge? Cool, address spaces. It's not the CPU memory, yeah, exactly, right? And then the file we just talked about, right? Which is the disk, okay? And all of these abstractions, again, are gonna consume us for a great deal of time, but what we're gonna start with today is at the top, right? So, we're starting with an abstraction that actually doesn't map down to any physical part of the system, all right? Okay, so, the process, right? The process is sort of the king abstraction. It's the most fundamental operating system abstraction, and the process, again, doesn't really map down to any specific hardware resource because it organizes information about everything that a single process is doing, right? So, what do you guys typically, what are other names that you guys typically use for process? Task, okay, somebody's been hacking on Linux too much. What else? Yeah? Program, it's another one, what else? Jobs, somebody's been running batch jobs on a machine that's on a server. Okay, jobs, what else? You know, I mean, come on, you guys are normal, right? Applications, how about apps, right? Now, these are just all synonyms for a process, right? And processes are designed to represent and encapsulate a bunch of information about a single thing that from your perspective, right? And this is doing in a very loose sense, right? A single thing that the system is doing, right? There's an app that's called Chrome and that app is retrieving and rendering websites, right? There's an app that's called iTunes or an application, a process, task, job, whatever, that iTunes is organizing its own information and it's designed to provide you access to media, right? And again, you have lots of different names for processes, right? But a process, you guys have a very intuitive feeling of what a process is, right? And again, unlike threads, processes don't map down to a hardware component. They contain other abstractions, right? So a process is made up of who can map from the pictures into the bullets, right? What does a process contain? What sort of other abstractions are inside this process container? What about, say, someone's, he's gonna have to say that name for me. See here? Nope. Again, what's inside the process? Threads, yeah, there's a couple of threads, so this process has three threads, right? What else is inside the process? Wait, how? Memory, so what's the abstraction for memory? It's up there. Address space, right, yeah. So the address space that's abstracting the memory and what's, and files, what else? Have I missed something? Nothing? Would this be a, would this be a program that you guys would enjoy using? What can this program not do? Yeah. What's that? Instructions. Yeah, instructions are really, are really something that we're gonna be, it's gonna be sort of a, the executions interplay between the memory and the thread, yeah. Oh, I didn't even think of that. Yeah, it'd be nice to have a GUI, right? Because otherwise you can't see it. What else? Okay, yeah, it'd be nice to be able to talk to the process, right? What else? Yeah, yeah, we got that one. So to some degree, what we're gonna, actually what you guys are gonna discover is that UNIX-like systems, which is what we're gonna study, tend to make all IO look like a file, right? So it turns out that files of the abstraction that get reused over and over again to make everything, that everything that's really some other type of device, look like a file, right? But again, there's one pretty big abstraction here that I think you guys would miss. Yeah, what's that? Yeah, it's not an abstraction. What other part of the system? There's no what? The threads are, we're gonna figure that out with threads. What's missing? Come on guys. What can this, what can this not do? Yeah. Yeah, you guys would probably appreciate a network, right? So that you can, you know, like, has anyone ever tried to use their computer without the internet? It's pretty depressing, right? It's like, man, this is terrible. No wonder they have Wi-Fi on every plane now and they charge you like $1,000 for it. All right, so to some degree, one of the things that we, you know, other than organizing information about sort of one thing that the computer is doing, processes also serve as a protection boundary. So an operating system has a contract with processes on the system, right? And we'll get into this next week when we start talking about why the operating system is in charge, right? Because the operating system, like we said before, is a program, it's a process. It's like other processes, but it's special, right? And it's, as being special, part of the reason that it gets to be special is because it makes this agreement with other apps on the system, right? The agreement is that you are allowed to do a lot of stuff inside your own process, right? That's not my problem, right? How you wanna do things inside your own process is not something that the operating system is gonna bug you about, right? However, you should also not be able to bother other processes, right? Now, that doesn't necessarily mean you can't communicate with them at all, but it does mean that you can't cause them to crash, right? So this is really sort of one of the fundamental tasks of modern computer operating systems is isolation, right? I want to allow processes to run as efficiently as possible, but I also wanna prevent process A from doing something, anything to the machine that would cause process B to crash, okay? And those things can really fall into two categories, right? One category is I somehow poke process B and get it to crash, right? So early versions of Windows actually had this problem, right? Where they had ways that processes were able to share certain resources without intending to, right? And so process A could actually get process B. If I knew what to do and I was malicious, I was mean, I could get process B to crash. What's the other way that I can get process B to crash? That the operating system would also like to prevent, yeah. Yeah, that's not really gonna cause it to crash, but you're right, there is a resource allocation problem that the operating systems are also trying to solve, but I'm just talking about protection now. There's another way that I can get process B to crash, yeah. Yeah, so that's sort of like the isolated attack on process B. But what's the most drastic thing that I could do? I really wanna take down process B, right? I think someone said it over here. I can crash the whole computer, right? Now it's all like I'm gonna go down with process B, right? But that's another thing that operating systems wanna prevent, right? I shouldn't be able to crash the entire computer, either, right? Even if I'm at a process B and I'm willing to sort of take one for just, yeah, say, scorched earth, right? Okay, so, and what the sense of meaning is that again, communication within your process is easy, right? Now it's not necessarily easy, right? But it's easier from the perspective of the operating system. The operating system doesn't tend to manage this, right? So usually when your process wants to communicate between multiple parts of the same process, it uses shared memory or other shared resources that are within the process itself, right? And threads that run within a process also share other types of state, right? And we'll get back to this when we start talking about the system call interface. So, and there are other types of information that are private, we'll come back to this, right? On the other hand, what you guys are gonna discover when you start writing your operating system kernel and start doing assignment one is that, despite the fact that this is possible, communication between multiple threads running in a single process is not easy, right? Because you have to worry about a lot of timing effects. How many people have ever had to deal with these in some sort of multi-threaded program? Okay, good. By the time you guys are done with this class, all your hands will be up, right? Because synchronization is a real problem and it's something that we'll spend some time on in class. And you guys would have a chance to do it for assignment one, all right? If I'm trying, now what the protection boundary means is that when I'm communicating between multiple processes, that's a little bit more difficult to accomplish, right? And the reason is because I wanna make sure that I'm successfully isolating processes from each other, right? If I allow processes to communicate with other processes, the way they do internally, it would be very easy for a process to crash another process, right? If I could just, you know, as Allison pointed out, if I could just write into another process's memory, right? Which threads can do, threads can do that to each other within the same process, but if I could just do that to another process, all bets are off, right? And some of you guys will probably find yourselves doing that to yourself as part of writing some of these assignments. Your kernel will be crashing and the reason your kernel is crashing is some thread that you programmed wrote some bogus stuff into memory somewhere and some other thread read that bogus stuff and then did something totally wrong, right? So if I allowed this to happen between processes, I'd be in big trouble, right? There'd be really no way to have a modern computer system. However, there are ways to accomplish IPC between processes, right? And we'll talk about these, but these methods are all really structured, right? They all, and they all require coordination between the two processes because remember, I don't, you know, I'm not going to create a relationship where none exists. If two processes want to communicate with each other, there are ways that they can do that. If they don't want to communicate with each other, they shouldn't have to, right? I shouldn't be forced into some sort of relationship with another process that I don't want to really, really happen, right? And again, a lot of these have these semantics limiting the degree to which you can actually interfere with other processes, right? Okay, so let's start actually looking at some of these mechanisms, right? And now we'll start looking at some examples drawn from the Linux command line, right? And these are all things that you guys can actually experiment with. How many people have access to a Linux or Unix-like system? I mean, everybody does, like Timberleague, but you guys can, I would suggest playing around with some of these in your VM, right? I mean, be careful, you don't want to blow the whole thing away, right? But at least in your VM, you can do dumb things, right? And you have pseudo access, so you can do some things that hopefully you should not be able to do on Timberleague, right? Like RM-RF flash, right? We did that once in the lab, just to see what would happen. It was actually not that interesting. It took a long time. So that was the way that we shut down one of Carl's machines. Carl was done with it, and we just decided, hey, he doesn't want it anymore, so let's see what happens. And it was not, again, don't do it, it's not very interesting, it's just sort of boring. All right, so one way that processes communicate with each other, and you guys will actually be implementing some of this for assignment two, is through what are called return codes, right? So here's an, when a process has a child, and that child process exits, and we'll talk about how processes create these child processes, but in certain cases, processes can retrieve one, you know, like two or four bytes of information about that process. So here's what happens up here. I run the command bin true in the background, and then I have the shell wait on it, right? When bin true exits, what happens is that the shell tells me that it exited, right? And it tells me what the return code was, right? In this case, it tells me it's done. Here's the job ID, this is that it's finished. In this case, I ran bin false. Does anyone know what bin true and bin false do? Yeah, yeah, so bin true is the simplest possible program you can write and see. In fact, I'm not sure there's even a main function, but there probably is, right? But if it is, it's empty, right? It returns zero. Why zero? Anyone know this? Yeah? Yeah, so zero is typically the exit code that indicates fine, right? Nothing to report. What is, so bin false reports one, right? Now anything other than zero as an exit code usually means something went wrong, right? If you run false, what it indicates is you ran bin false, right? And that was the problem, right? But other types of programs will return exit codes, and if the exit code is non-zero, again, it usually means that there's some type of error that took place or some sort of unexpected condition, and in certain cases that exit code will, if you look it up, that exit code will actually tell you what went wrong, right? Or give you a hint as to what caused the program to crash or not to execute completely, okay? So I did the same thing here. I ran bin false in the background and I waited for it and here what the shell tells me is that it exited, and because it exited with an exit code that was not zero, it also tells me what that exit code was, right? So exit codes, one simple way of doing IPC, right? Really nothing that can go wrong with exit codes, right? Partly because, so what's interesting about exit codes is the form of IPC. Again, inner process communication, I wanna be very careful when I arrange it because I wanna make sure that the processes can't interfere with each other, right? What's nice about exit codes? What's particularly, yeah. The process, by the time the process receives the exit code, the other process is terminated, right? So there's nothing else I can do to it, right? I can't bother it. There's no way for a parent to really abuse, or a process to abuse this mechanism, right? It just, because again, by the time I get it, the process is already exited, right? So an exit code is not a form of IPC that happens while the processes are both running. It's only received after the process that generated it exits, okay? Got it. Let me just all talk about this, right? If you didn't know this, how many people knew this about bash? Yeah, there we go. So if you've ever run a command and wanted to know what the exit code was, this little bash built in will tell you what the exit code was, right? Little things that you wish you knew about the world, right? Or maybe you wish you didn't know that, and I just told you, and now I just ruined your whole day, but whatever. Okay, so same thing here. Similar example, just having, because sometimes you run a command and you forgot to ask bash for the exit code, so this will tell, right? Bash notes, okay. Pipes, right? How many people have used pipes before? There we go, yeah. So pipes are another simple form of IPC and possibly sort of one of the most interesting and powerful early, early day programming mechanisms, right? So pipes allow me to chain two processes together so that one process receives the output of the other process, right? So when I run this command, what will happen is that PS will run, PS is one process, AUX are some flags to PS to tell it what to do, and then grep is going to run. And the system is going to set this up, the shell is going to set this up for you so that all the output that PS generates is going to be read as input by grep, right? And you can use these to write arbitrarily long, you know, pipelines of small little Unix commands, right? So pipes create this producer-consumer buffer between two processes, right? Again, this is a nice form of IPC because it's reusing mechanisms that processes already deal with, right? So PS and grep already handle input and output, right? Grep can take input from standard in and generate output to anything same with PS, right? So the nice thing here is, again, I'm not altering the processes' behavior and these two processes may not even know that they're chained up in this way, right? They're just, grep is like, hey, I got some input, I don't know where it came from and I did what I do, right? I just looked for that string, okay? Yeah, there we go. Here's my mem for the day, right? Ted Stevens, series of tubes. Yeah, and if you've never done any programming, you can have these, I probably should have gone to some website, you can probably go on Google and find worst Linux pipe example ever and it probably is like 60 lines long of commands piped. All right, so signals, right? Signals are another form of IPC, right? And signals in a weird way, how many people have studied RPC or any sort of remote procedure calls stuff? If you guys are taking distributed systems, you guys will probably talk about that at some point. Signals are almost a little form of local remote procedure calls, right? So a signal essentially allows one process under certain conditions to trigger behavior in another process, right? So you could think about it, I register a function and then signals give me a way to call a function in another process, right? By sending it a signal, by telling it, here's the function I wanna run. Now this is really limited. It's not RPC, it's nowhere close to that. RPC would allow me to potentially run any function, right? But signals give processes a lot of control over how this works, right? So how many people have ever used a signal before? Okay, everybody put up your hand. How many people have ever used a signal before? I'm serious, everybody put up your hand. This is the correct answer, okay? You guys that didn't know used a signal. Does anyone who thinks they've used a signal want to explain to someone who didn't think they used a signal why I think they're wrong? Yeah, control C. How many people have you ever used control C? There we go, right? That's how control C works, right? Would you just think it was magic, right? Control C sends a signal to the process that's running in your terminal. That signal is called sigterm. That signal is a polite way to ask that process to stop running, right? Most processes are set up to exit when they receive that signal. However, it's not required that the process exit. Has anyone ever tried to control C a process and it didn't work? Yeah, you guys should stop running viruses. No, just kidding. I mean, you can do this by accident or on purpose. I don't know why, but anyway. So in certain cases, the process may choose to ignore that signal, right? And so there isn't, so kill, right? So kill is actually a funny unit command. Kill can send any signal, right? But for some reason it's called kill. You could call it signal, right? Someone, whoever wrote this was angry, was an angry person, clearly, because they called it kill, but you can use kill to send any signal. By default, kill sends sigterm. So maybe that's why it's called kill, I don't know. But you can, again, you can have kill issue any signal, right? Here, what I've done is I've called kill-9. Now kill-9 is a special signal it's called sigkill, right? Sigkill cannot be ignored, right? Sigkill will always terminate the process. There's nothing else that can happen, right? And actually sigkill I think is handled by the operating system. Now what's a problem with this, right? Weren't we talking about something like 10 minutes ago? Something about like not allowing processes to interfere with each other. So what's wrong with kill? What's wrong with kill-9? Yeah, yeah, I don't wanna be killed. I was doing something, right? I was like doing something useful, right? I don't want to be killed. And so normally, in order to send sigkill to a process you either have to be the owner of that process. So it's assumed that you know what you're doing with the processes you created. Maybe the process doesn't wanna be killed but you're in charge. Or if you're a super user on the machine, you can use pseudo to send a kill command to everything. And this is one of my, this is by far my favorite XKCD cartoon. It is just the funniest. So yeah, this is, you guys have ever used a Unix machine, okay. Okay, so we'll come back to IPC, right? You guys will do return codes for assignment two. Pipes we'll talk about when we talk about fork. Signals we're gonna mainly ignore because signals are pretty hard to get right, yeah. Yep, no. So kill is the one command that, in fact, you may be able to register a handler and it may run but I'm pretty sure after it runs you die, right. Like, you know, and maybe not even that, right. I think I'm not even sure you can register handle with sigkill, I'd have to look it up. But sigkill, essentially what happens is signals are always sent through the operating system, right. And the operating system just enforces that after sigkill that process has to exit, right. It can choose to exit or I can exit it for itself, yeah. Well, again, yeah, that's a good point. So I'm probably wrong, right. Probably the correct answer is no, you cannot register a signal handler for sigkill, right. Because you're right, like someone could do something that would cause some sort of unintended side of it. So no, you could, yeah, that's a good point. You would not want to be able to let a process do something. So I suspect that what happens with sigkill is that the operating system just kills the process. But actually that's a good question, I'll look into that. I mean, you could try to do a fork but if OS knows you're inside a signal handler, probably we'll just not allow you to do it, right. Okay, and then, and share in memory really didn't talk about, I guess we talked about that first, but we'll talk about that when we come back to virtual memory. You guys will not have to implement share in memory, although it would be awesome to do as a part of assignment three. Okay, so I just want to touch up a little bit of terminology that's been sort of finished up today. There are some confusing overlaps between processes and threads, right. Typically because we talk about both of them in similar ways, right. So we can talk both about a process and a thread as running, right. Usually by running, and we are gonna start to get more precise about what we mean when we say the things that we say now, right. Because when we talk about something running on your computer, it may or may not be really running, right. It may not be actively using the CPU, for example, which is a state that most of us would refer to as not running, right. But we can talk about a both as process as a thread is running, we talk about a process running when one of its threads is actively using the CPU and we talk about a thread running when it's actively using the CPU, okay. And just keep this in mind, just keep in mind what a process is, right. A process is a container into which we put other abstractions, right. So if a processes thread is running, then we can talk about the process of being running. A thread of execution is actually a specific way of abstracting away details of the CPU, right. And again, that's the first thing that we'll start talking about once we get done talking about sort of the OS from viewed from above, right. Which is what we're doing now. Processes contain threads, right. Threads belong to a process. The only exception to that kind of is the kernel which can have threads that are not attached to any user process. But again, if we come back to our idea that the kernel is just a process, then those threads are really part of the kernel process. Okay, yeah, like we said, there's lots of different terminology for process. In particular, if you guys are looking up stuff about Linux, Linux uses a task as to talk about process and has other words for other things, right. So you just, whenever you're talking, when you're, if you want to read up about other operating systems, just make sure that you have their terminology straight, right. So let's walk through an example of Firefox and think about some of the ways that Firefox might be using resources, right. So Firefox undoubtedly, and I used to, I have to say, I've hit a personal milestone this year. Every year when I would get to this slide, I would have this little thing about how I'm such like a grumpy old grandpa because I still use Firefox, right. As opposed to Chrome, I now use Chrome, right. So anyway, I mean maybe there's some new cool thing you guys are using like Super Chrome or whatever. But I'm using Chrome and I'm proud of that. It took me a while to convert. So Firefox is, but Firefox in theory, which I don't know anything about first hand anymore because I don't use it anymore because I'm all caught up. So Firefox would have multiple threads. What would the threads in Firefox be doing? Speculate about some of the things that Firefox threads could be doing. Harris, I don't know. What would, how would Firefox be using the CPU? Well, one way it could be like waiting for you to move the mouse, right. There's probably a thread following your mouse around, right. Maybe that's done in some sort of library, right. But certainly waiting for UI events. What else could Firefox be doing with a thread? Cun, yeah, doesn't know. Anyone else want to help these guys? Yeah, yeah, like something's got to convert that HTML to pixels, right. Like you don't get a, your pages aren't just a big JPEG, right. And actually if they were, you'd still have to decompress them, right. So yeah, I mean, something has to convert when you go to a website, right. Something has to take the contents that the server sent you and render them into the output that you see on the screen, right. So I think that's the next thing. Yeah, redrawing the screen. If I type things into text boxes, what happens a lot now, so what are other threads in Firefox doing, right. So let me explain to you your experience of the web. You go to a website, you download a page and then that page just sits there doing nothing, right. I mean, this is my Gmail inbox on a good day, right. But what's normally happening? What else is Firefox doing, yeah. But how, how is this magical thing happening? Yeah, so it might be some JavaScript running, right, which is redrawing the page, right. I mean, your modern experience of the web is essentially all driven by JavaScript, right. That's how every modern web app that you use works, right. So what does Firefox use memory for? What would Firefox store in memory? Yeah, yeah, I load the page from the network into memory and that's where the page data is stored as I do my rendering, right. What else? Yeah. Yeah, like any sort of sort of runtime data, right. Variables used by JavaScript, you know, state that's needed for plugins, et cetera, right. And how about this? How about the executable code of the program, right. It's gonna be difficult to render my webpage if I don't know how to do it, right. And the way I know how to do it is that there's a part of memory where the instructions that are being fetched by the processors that runs the rendering engine are stored, right, that has to happen, right. I put shared libraries in there, et cetera, right. I've got dynamically out of memory, these are just examples, you guys can look at these offline, okay. What would Firefox be using files for? Files, I mean, it's a web browser, right. It doesn't need any files. Does it need files? Yeah. Yeah, sure, anything that's gonna stay, anything that you wanna persist, right, between sessions, like I shut down my web browser and I open it up again and I won't have to re-log into every website on Earth, right. I mean, it's easy for me because my password is the same for every website. And it's, you know, pretty kitty, sorry. Anyway, so, yeah, any of this state that Firefox wanna persist between these sessions, you've gotta store that on the desktop, right. And then things like configurations, right, stuffy. And font files, a lot of web browsers cache a lot of stuff, right. Because I wanna cache things so that I can avoid downloading everything again, right. You guys should try this sometime, I mean, take a web browser you've been using and go into that scary panel about security and just clear out everything, right. Like the cache, everything forever, right. And then see how frustrated you are for the next 10 minutes, right. As like everything is slow and everything has to reload everything from, and then yeah, and then go home where your parents have like dial-up internet. And then you'll wanna, you'll be running back to you be immediately. Okay, so I'll just show you a couple ways you could retrieve. How many people have used top before? Okay, so you guys kinda know what's going on here. I'm not gonna go through this in detail. So PS, PGREP, people familiar with these tools. But you know, as we go along, I mean, I wanna make sure you guys are connecting some of what we're talking about in class to real systems, right. Because sometimes we get a little bit abstract in here. So take these out, you know, when you have some free time when you're sitting around and your partner's trying to debug the code they checked into your repository. And you know, run these utilities and poke around and see what's going on, right. So, you know, and you can essentially, what you can start doing is filling in some of the pieces of this mental model, right. So for example, here's something I ran on bash, right. And this gives you an enormous amount of information. I'm not gonna go through all this. You guys can look at this offline. Now here's an interesting way to do this. So if bash had multiple threads running, this particular command would show me all the bash's threads. Why doesn't bash have multiple threads running? It's because bash is this ancient tool that's not cool and multi-threaded anymore. Is that why? Why doesn't bash use multiple threads? Wouldn't that be the awesome? Does bash need multiple threads? What does bash do? What does a shell do? What does its life consist of? Yeah, yeah. Yeah, bash does nothing in the back row, right. The bash does not need a thread, right. Bash waits for your input. It does, it tries to do what you told it to do. And then it redraws the prompt, right. So no need for bash to have multiple threads, right. The bash has a single thread. Here's an example of something with multiple threads, right. Apache, what is Apache? It's a web server, right. The web server is a conical example of something that has multiple threads, right. And in fact, Apache not only uses multiple threads, but also uses multiple processes, right. A terrible, gory mix of both, right. Just to improve performance, right. So how many people have ever used PMAP? Now we're gonna get into the more obscure Linux command. PMAP, oh, this is a cool command. So PMAP will actually print out the memory contents of the address space for the process, right. So this is pretty cool, I ran it for bash. What do you think, so this is, now you guys don't know anything about this yet, but we'll fix that this semester. But what do you think it's telling me right here? These first three parts of the address space of bash. What is in there? What is that memory storing, yeah. Yeah, that's the program executable, right. And bash has one part that's marked executable. Now what about this part, right. So these are permission flags, right. You guys are probably familiar with those. You've seen those on files before, right. What is this, this means read and what's x? Executable. So this is the actual bash executable, right. What's this section right here? Why is it read only? It's bash, but it's read only. It's not marked executable. So there's no code in here, what's in here? What's that? No, no, no, no, this is not a file. Don't be fooled, these are memory, yeah. Yeah, like any constants that are defined in the program, right, are loaded in here, right. What's this area? It's read right, but it came from bash, right. So this area stores variables for out of time. So this area stores variables that were initialized by bash when it loaded. So they came in the bash executable, but they're also marked as read right. So there are things that can change at runtime, okay. We will pick up here on Monday. I'll see you guys then.