CS/CE 218 Lecture -*-Outline-*-

connection: pipelining is one kind of parallelism on unix.
	    but it's sometimes useful to have processes running
		in parallel but not working together

* background processing

advert: the shell's primitives for parallel computing (operations on processes)
	perfect for impatient people, do something else while computing,
		do 2 or more things at once.

** forking a process (creating a background process)
	the syntax for prallelism is as follows
	---------
	gcc -g gigantic.c 2>&1 >gcc.out & mail
	---------
		runs gcc and mail in parallel
		puts gcc in background
	output is something like
		-------------------
		[1]     19583		(job #	process id (pid))
		No mail.
		-------------------

	Q: How would you explain the choice of '&' in the shell?
		do this *and* whatever else...

	some tips
		be polite!
			there's only 1 CPU...

		not wise to put mail in background
			then you would have the shell competing with mail
				 for your input

	Q: What should you do with the output of a background process?
		fun to try cat'ing two files in parallell to see what you
			don't want to happen

	You don't have to decide what to do in parallel with the background
		gcc -g gigantic.c 2>&1 >gcc.out &

*** forking a pipeline
	pipelining is orthogonal to forking...., so can do both at once

	------------------------
	tbl file.tr | pic | troff >file.formatted &
	------------------------
	what's the precedence of > | and &?

*** job control in korn shell and c-shell
	when you fork several jobs, you may want to
		know what they're doing
		kill one of them...

	background pipelines given a job number (printed in square brackets)

	^Z suspends the foreground pipeline (not running)

	bg makes it run in background (like &)
	fg makes background job a foreground job
		e.g., emacs ... ^Z, ..., fg (resumes emacs)
		can use job number: fg %1
		or command name: fg %emacs

		running in foreground (shell sleeping)
                           |                  ^
			  ^Z		      |
                           |		      fg
       	       	       	   v		      |
			stopped  ====bg=====> running in background
		(shell running)			(shell running)

	see manual page under job control for more details


** status of processes (observing processes)
	A job is an ADT specific to the shells
	Unix has an ADT called processes
		we've already seen how to create them.
		What other things to do? (observe, modify, destroy)
	to observe, use the ps command

	by default ps gives info on your processes,
		especially important is the process id number (PID)
		read the manual page for more info
----------------
   PID TTY      TIME COMMAND
 19544 ttyt1    0:00 ksh
 19699 ttyt1    0:00 ps
----------------

	Q: Is running "ps" a legitimate foreground task?
		sometimes, but not if you aren't doing anything else
			or going away

*** killing a process (page 107)
	to kill, use the kill command

	for example, the usual way to kill an editor is
		kill -1 pid
	acts like you hung up the phone (signal 1 = HANGUP)

		in ksh can say
			kill %1
		to kill job 1

	Q: do you think you should be allowed to kill processes owned
		by other users?
		you can't
	can the superuser?
	Q: How do you kill a process that is ignoring signals?

	Q: What would you do if a program you were running in the foreground
		got into a state where it didn't respond to your interrupts?

** other process attributes
	processes have other attributes besides background/foreground
		and file descriptor mapping
	important ones are their priority (for scheduling) and how
		they handle interrupts
	most attributes shown by ps -l
		(but now how interrupts handled, too hard to classify code)
---------------
$ ps -l
  F S   UID   PID  PPID  C PRI NI   ADDR  SZ    WCHAN TTY      TIME COMD
  1 R   111 19737 19544  4 179 20  ff2d1  47          ttyt1    0:00 ps
  1 S   111 19544 19543  0 168 20  feb6f  69   d02000 ttyt1    0:00 ksh
---------------

*** process priority
	process priority is it's "nice value"
		20 is normal
		0 would not be very nice, so high priority
		39 is as nice as it gets
	Q: Why would you want a lower priority?
		just to be nice...

	If you forgot to nice a command, can use renice...

	Can you lower the priority of a pipeline?
		yes, clearest way to do it is:
		nice /bin/sh -c "foo | bar |...| baz"

*** protecting against hangup signals
	one attribute is how a process handles interrupts (signals)
		code in general
	one signal is sent when user logs out
		e.g., when modem hangs up (by accident)
	use nohup if you plan to log out and want program to keep running
	Q: Do you think the order of nohup and nice matters?
		it doesn't
	have to remember to do nohup ahead of time.
		why?