COMP 3000 2011 Week 2 Notes
Process: abstractraction for keeping programs separate
Program Image: memory of a running program (the "core"). Combined with execution context to create a process.
Core Dump: what you get when a program crashes if you were lucky and enabled it--takes the core image--all in memory--and writes it to disk.
Wait: parent process claiming return value of child
Shell: interface for interacting with the system--managing resources and programs; an interface to do system calls
Permission (file system): in UNIX all files fit into a single hierarchy
Links: files are just pointers to inodes (hard links)
- Inode: the index node is the intermediate name to access/refer to a file. Multiple files can refer to the same inode; if so, then the files are just different names for the same content: if you change one file, it is reflected everywhere. You can't delete a file in UNIX, you can only unlink it (remove a reference to its inode). The system will know to delete a file when all the links to an inode (reference count) is zero. The metadata for a file and permissions are all located in the inode.
Application vs. Process:
- An application can run multiple processes
- Process can run without our knowledge and in the background all the time
- There is only one copy of a program on disc and in RAM even if you're running multiple processes executing the same program binary. 5 copies of a program will not take up 5 times the memory - the code is shared between them (but data is specific to each process).
- Virtual: all of a program's code and data--how much memory the program thinks it has
- Resident: amount of memory used in physical memory (RAM)
- Shared: memory shared with other processes. This is usually in the form of libraries (UNIX's response to the linking problem--avoid having multiple copies of a function in memory, which is just a waste of space).
Fork vs. Execve
Fork: Calling fork will preserve the parent process (the original process ID) and create a child (new process)--a copy of the parent process
Execve: takes a file and loads the program binary but doesn't make a new process--it uses the process that made the execve call (i.e. the program that calls execve kills itself by running execve and loading a new program binary)
Zombie Process: parent process still needs to claim the return value of the child process, otherwise a dead child turns into a zombie. To kill a zombie process you need to kill the parent - this will cause the zombie to become a child of init (PID 1) and init will call wait, retrieving the return value.