COMP 3000 2011 Week 2 Notes: Difference between revisions

Latest revision as of 03:16, 6 November 2011

UNIX Basics

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, Resident and Shared Memory

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.

@@ Line 3: / Line 3: @@
 '''Process''': abstractraction for keeping programs separate
-'''Program Image''': binary program written to disc; creates a running program in memory
+'''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 disc
+'''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 (system calls)''': interface for interacting with the system--managing resources and programs; an interface to do system calls
+'''Shell''': interface for interacting with the system--managing resources and programs; an interface to do system calls
-'''Permission (file system)''': in UNIX everything fits into a single hierarchy
+'''Permission (file system)''': in UNIX all files fit into a single hierarchy
-'''Links''': using pointers to refer to files
+'''Links''': files are just pointers to inodes (hard links)
-* '''Inode''': the index node is the intermediate name to access'refer to multiple files. If you change one file, it is reflected everywhere. You can't delete a file in UNIX, you can only unlink it. 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.
+* '''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 procresses
+* 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 even if you're running multiple processes (i.e. multiple copies of the program are open). In other words, 5 copies of a program don't take up 5 times the memroy.
+* 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, Resident and Shared Memory===
@@ Line 25: / Line 25: @@
 # '''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 usally in the form of libraries (UNIX's response to the linking problem--having multiple copies of a function in memory, which is just a waste of space).
+# '''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. Exec ve===
+===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 program binary (same binary but new process)
+'''Fork''': Calling fork will preserve the parent process (the original process ID) and create a child (new process)--a copy of the parent process
-'''Exec ve''': takes a file and loads the program binary but ''doesn't'' make a new process--it uses the process that made the exec ve call (i.e. the program that calls exec ve kills itself and the new program binary is loaded)
+'''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. To kill a zombie process you need to kill the parent.
+'''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.