COMP 3000 2011 Week 2 Notes

From Soma-notes
Revision as of 03:16, 6 November 2011 by Soma (talk | contribs) (→‎UNIX Basics)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)

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

  1. Virtual: all of a program's code and data--how much memory the program thinks it has
  2. Resident: amount of memory used in physical memory (RAM)
  3. 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.