COMP 3000 Lab 3 2010 - Revision history

Zliu10: /* Fork & Exec */

2010-10-05T15:20:53Z

Fork & Exec

← Older revision		Revision as of 15:20, 5 October 2010
Line 26:		Line 26:

	# What is the difference between the <tt>clone</tt> and the <tt>fork</tt> function call?		# What is the difference between the <tt>clone</tt> and the <tt>fork</tt> function call?

	~~with fork(), you get a new process. and you can use exec( ) to replace the parent process by the child process.~~
	~~with clone(), you get a new thread, it shares some property with the process. and you can not replace the process by this thread.~~

	===IPC===		===IPC===

Zhangqi: /* Processes and Threads */

2010-10-05T15:20:18Z

Processes and Threads

← Older revision		Revision as of 15:20, 5 October 2010
Line 18:		Line 18:

	# The program [http://homeostasis.scs.carleton.ca/~soma/os-2010f/lab3/threads.c threads.c] is a multithreaded producer/consumer program. Unfortunately it consumes faster than it produces, resulting in an error. Why does it not print the same number every time?		# The program [http://homeostasis.scs.carleton.ca/~soma/os-2010f/lab3/threads.c threads.c] is a multithreaded producer/consumer program. Unfortunately it consumes faster than it produces, resulting in an error. Why does it not print the same number every time?
	~~A: The two programs run paralle. Scheduling.~~

Zhangqi: /* Processes and Threads */

2010-10-05T15:20:08Z

Processes and Threads

← Older revision		Revision as of 15:20, 5 October 2010
Line 22:		Line 22:

	# The program [http://homeostasis.scs.carleton.ca/~soma/os-2010f/lab3/passstr.c passstr.c] is a multithreaded program using the <tt>clone</tt> function call. What is wrong with the way this program blocks, waiting for the string to arrive in the buffer?		# The program [http://homeostasis.scs.carleton.ca/~soma/os-2010f/lab3/passstr.c passstr.c] is a multithreaded program using the <tt>clone</tt> function call. What is wrong with the way this program blocks, waiting for the string to arrive in the buffer?
	~~A: When we run the maker_func(),we meet sleep(1). The the CPU jump to printer_func().~~

	===Fork & Exec===		===Fork & Exec===

Zliu10: /* IPC */

2010-10-05T15:20:05Z

IPC

← Older revision		Revision as of 15:20, 5 October 2010
Line 47:		Line 47:
	## The permissions must be specified as a value. By reading the manpage of chmod, determine what the permission 0760 means.		## The permissions must be specified as a value. By reading the manpage of chmod, determine what the permission 0760 means.
	## What number is going to be required in order for two processes owned by the same user to be able to read and write to the shared memory?		## What number is going to be required in order for two processes owned by the same user to be able to read and write to the shared memory?
	1.
	~~1. TERM~~
	~~2. signal(SIGCHLD, child_handler); and the definition of child_hander (only one arguments)~~
	3
	~~1. the third: shmflg~~
	~~2. user can read+write+execute; group can read+write, others cannot do anyting.~~
	~~3. 0600~~

	==Part B (Optional)==		==Part B (Optional)==

Zliu10: /* Processes and Threads */

2010-10-05T15:17:33Z

Processes and Threads

← Older revision		Revision as of 15:17, 5 October 2010
Line 22:		Line 22:

	# The program [http://homeostasis.scs.carleton.ca/~soma/os-2010f/lab3/passstr.c passstr.c] is a multithreaded program using the <tt>clone</tt> function call. What is wrong with the way this program blocks, waiting for the string to arrive in the buffer?		# The program [http://homeostasis.scs.carleton.ca/~soma/os-2010f/lab3/passstr.c passstr.c] is a multithreaded program using the <tt>clone</tt> function call. What is wrong with the way this program blocks, waiting for the string to arrive in the buffer?
	A: When we run the maker_func(),we meet sleep(1). The the CPU jump to printer_func().		A: When we run the maker_func(),we meet sleep(1). The the CPU jump to printer_func().

	2. The printer_func keeps checking the buffer, before it could get arg, it will never quit automatically. the only chance for maker_func to run is, when printer_func runs out of its quantum, and CPU is scheduled to maker_func. It is a waste of time. A better method of waiting is sleep for 1ms, then check.

	===Fork & Exec===		===Fork & Exec===

Zhangqi: /* Processes and Threads */

2010-10-05T15:14:49Z

Processes and Threads

← Older revision		Revision as of 15:14, 5 October 2010
Line 18:		Line 18:

	# The program [http://homeostasis.scs.carleton.ca/~soma/os-2010f/lab3/threads.c threads.c] is a multithreaded producer/consumer program. Unfortunately it consumes faster than it produces, resulting in an error. Why does it not print the same number every time?		# The program [http://homeostasis.scs.carleton.ca/~soma/os-2010f/lab3/threads.c threads.c] is a multithreaded producer/consumer program. Unfortunately it consumes faster than it produces, resulting in an error. Why does it not print the same number every time?
			A: The two programs run paralle. Scheduling.


	# The program [http://homeostasis.scs.carleton.ca/~soma/os-2010f/lab3/passstr.c passstr.c] is a multithreaded program using the <tt>clone</tt> function call. What is wrong with the way this program blocks, waiting for the string to arrive in the buffer?		# The program [http://homeostasis.scs.carleton.ca/~soma/os-2010f/lab3/passstr.c passstr.c] is a multithreaded program using the <tt>clone</tt> function call. What is wrong with the way this program blocks, waiting for the string to arrive in the buffer?
			A: When we run the maker_func(),we meet sleep(1). The the CPU jump to printer_func().

	2. The printer_func keeps checking the buffer, before it could get arg, it will never quit automatically. the only chance for maker_func to run is, when printer_func runs out of its quantum, and CPU is scheduled to maker_func. It is a waste of time. A better method of waiting is sleep for 1ms, then check.		2. The printer_func keeps checking the buffer, before it could get arg, it will never quit automatically. the only chance for maker_func to run is, when printer_func runs out of its quantum, and CPU is scheduled to maker_func. It is a waste of time. A better method of waiting is sleep for 1ms, then check.

AbsMechanik: /* IPC */

2010-10-05T15:11:58Z

IPC

← Older revision		Revision as of 15:11, 5 October 2010
Line 36:		Line 36:
	## Modify the [http://homeostasis.scs.carleton.ca/~soma/os-2010f/lab3/wait-signal.c wait-signal.c] file to use the signal function to install the signal handler instead of the sigaction function call. You can have it install the child handler alt signal handler instead of the child handler signal handler. What line did you add to install the signal handler to child handler alt?		## Modify the [http://homeostasis.scs.carleton.ca/~soma/os-2010f/lab3/wait-signal.c wait-signal.c] file to use the signal function to install the signal handler instead of the sigaction function call. You can have it install the child handler alt signal handler instead of the child handler signal handler. What line did you add to install the signal handler to child handler alt?
	## Modify the [http://homeostasis.scs.carleton.ca/~soma/os-2010f/lab3/wait-signal-1.c wait-signal-1.c] file to ignore the abort signal. What line did you have to add to do this?<br /><br />		## Modify the [http://homeostasis.scs.carleton.ca/~soma/os-2010f/lab3/wait-signal-1.c wait-signal-1.c] file to ignore the abort signal. What line did you have to add to do this?<br /><br />
	Note: The file names may have been switched. Try using the wait-signal1.c for part 1 and wait-signal.c for part 2 - --[[User:AbsMechanik\|AbsMechanik]] 15:11, 5 October 2010 (UTC)		Note: The file names may have been switched. Try using the wait-signal1.c for part 2 and wait-signal.c for part 3 - --[[User:AbsMechanik\|AbsMechanik]] 15:11, 5 October 2010 (UTC)
	# <b>Pipes</b><br />Pipes (also called FIFO’s) allow two processes to communicate through a file handle. One process writes data into a file handle and the other process can then read that data out through a related but different file handle.		# <b>Pipes</b><br />Pipes (also called FIFO’s) allow two processes to communicate through a file handle. One process writes data into a file handle and the other process can then read that data out through a related but different file handle.
	## What happens to file descriptors across an <tt>exec</tt> call? Write a small program that tests this behavior, i.e. that opens a file, calls execve, and then the new program attempts to read from the previously opened file descriptor. Explain how this program behaves.		## What happens to file descriptors across an <tt>exec</tt> call? Write a small program that tests this behavior, i.e. that opens a file, calls execve, and then the new program attempts to read from the previously opened file descriptor. Explain how this program behaves.

AbsMechanik: /* IPC */

2010-10-05T15:11:37Z

IPC

← Older revision		Revision as of 15:11, 5 October 2010
Line 36:		Line 36:
	## Modify the [http://homeostasis.scs.carleton.ca/~soma/os-2010f/lab3/wait-signal.c wait-signal.c] file to use the signal function to install the signal handler instead of the sigaction function call. You can have it install the child handler alt signal handler instead of the child handler signal handler. What line did you add to install the signal handler to child handler alt?		## Modify the [http://homeostasis.scs.carleton.ca/~soma/os-2010f/lab3/wait-signal.c wait-signal.c] file to use the signal function to install the signal handler instead of the sigaction function call. You can have it install the child handler alt signal handler instead of the child handler signal handler. What line did you add to install the signal handler to child handler alt?
	## Modify the [http://homeostasis.scs.carleton.ca/~soma/os-2010f/lab3/wait-signal-1.c wait-signal-1.c] file to ignore the abort signal. What line did you have to add to do this?<br /><br />		## Modify the [http://homeostasis.scs.carleton.ca/~soma/os-2010f/lab3/wait-signal-1.c wait-signal-1.c] file to ignore the abort signal. What line did you have to add to do this?<br /><br />
			Note: The file names may have been switched. Try using the wait-signal1.c for part 1 and wait-signal.c for part 2 - --[[User:AbsMechanik\|AbsMechanik]] 15:11, 5 October 2010 (UTC)
	# <b>Pipes</b><br />Pipes (also called FIFO’s) allow two processes to communicate through a file handle. One process writes data into a file handle and the other process can then read that data out through a related but different file handle.		# <b>Pipes</b><br />Pipes (also called FIFO’s) allow two processes to communicate through a file handle. One process writes data into a file handle and the other process can then read that data out through a related but different file handle.
	## What happens to file descriptors across an <tt>exec</tt> call? Write a small program that tests this behavior, i.e. that opens a file, calls execve, and then the new program attempts to read from the previously opened file descriptor. Explain how this program behaves.		## What happens to file descriptors across an <tt>exec</tt> call? Write a small program that tests this behavior, i.e. that opens a file, calls execve, and then the new program attempts to read from the previously opened file descriptor. Explain how this program behaves.

Zliu10: /* Fork & Exec */

2010-10-05T14:48:02Z

Fork & Exec

← Older revision		Revision as of 14:48, 5 October 2010
Line 24:		Line 24:

	# What is the difference between the <tt>clone</tt> and the <tt>fork</tt> function call?		# What is the difference between the <tt>clone</tt> and the <tt>fork</tt> function call?

			with fork(), you get a new process. and you can use exec( ) to replace the parent process by the child process.
			with clone(), you get a new thread, it shares some property with the process. and you can not replace the process by this thread.

	===IPC===		===IPC===

Zliu10: /* Processes and Threads */

2010-10-05T14:44:52Z

Processes and Threads

← Older revision		Revision as of 14:44, 5 October 2010
Line 19:		Line 19:
	# The program [http://homeostasis.scs.carleton.ca/~soma/os-2010f/lab3/threads.c threads.c] is a multithreaded producer/consumer program. Unfortunately it consumes faster than it produces, resulting in an error. Why does it not print the same number every time?		# The program [http://homeostasis.scs.carleton.ca/~soma/os-2010f/lab3/threads.c threads.c] is a multithreaded producer/consumer program. Unfortunately it consumes faster than it produces, resulting in an error. Why does it not print the same number every time?
	# The program [http://homeostasis.scs.carleton.ca/~soma/os-2010f/lab3/passstr.c passstr.c] is a multithreaded program using the <tt>clone</tt> function call. What is wrong with the way this program blocks, waiting for the string to arrive in the buffer?		# The program [http://homeostasis.scs.carleton.ca/~soma/os-2010f/lab3/passstr.c passstr.c] is a multithreaded program using the <tt>clone</tt> function call. What is wrong with the way this program blocks, waiting for the string to arrive in the buffer?
			2. The printer_func keeps checking the buffer, before it could get arg, it will never quit automatically. the only chance for maker_func to run is, when printer_func runs out of its quantum, and CPU is scheduled to maker_func. It is a waste of time. A better method of waiting is sleep for 1ms, then check.

	===Fork & Exec===		===Fork & Exec===