COMP 3000 2011 Week 2 Notes - Revision history

Soma: /* UNIX Basics */

2011-11-06T03:16:36Z

UNIX Basics

Deadlytea: /* UNIX Basics */

2011-10-27T17:52:41Z

UNIX Basics

← Older revision		Revision as of 17:52, 27 October 2011
Line 19:		Line 19:
	* An application can run multiple processes		* An application can run multiple processes
	* Process can run without our knowledge and in the background all the time		* 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 even if you're running multiple processes (i.e. multiple copies of the program are open). In other words, 5 copies of a program will not take up 5 times the memory.

	===Virtual, Resident and Shared Memory===		===Virtual, Resident and Shared Memory===

Deadlytea: /* UNIX Basics */

2011-10-27T17:51:34Z

UNIX Basics

← Older revision		Revision as of 17:51, 27 October 2011
Line 17:		Line 17:

	'''Application vs. Process''':		'''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		* 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 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.

Gbooth: Created page with "==UNIX Basics== '''Process''': abstractraction for keeping programs separate '''Program Image''': binary program written to disc; creates a running program in memory '''Core D…"

2011-10-19T14:09:17Z

Created page with "==UNIX Basics== '''Process''': abstractraction for keeping programs separate '''Program Image''': binary program written to disc; creates a running program in memory '''Core D…"

New page

==UNIX Basics==

'''Process''': abstractraction for keeping programs separate

'''Program Image''': binary program written to disc; creates a running program in memory

'''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

'''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

'''Permission (file system)''': in UNIX everything fits into a single hierarchy

'''Links''': using pointers to refer to files
* '''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.

'''Application vs. Process''':
* An application can run multiple procresses
* 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.

===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 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).

===Fork vs. Exec ve===

'''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)

'''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)

'''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.

← Older revision		Revision as of 03:16, 6 November 2011
Line 3:		Line 3:
	'''Process''': abstractraction for keeping programs separate		'''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		'''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''':		'''Application vs. Process''':
	* An application can run multiple processes		* An application can run multiple processes
	* Process can run without our knowledge and in the background all the time		* 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 will not take up 5 times the memory.		* 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, 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		# '''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)		# '''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.