Exam 1: Oct 12 - Take home style. Runs total 2 hours between end of class and next morning (11 AM?)

- Details in this weekend's digest
------------------------------------------------------------------

Project 1: Dues Oct 7 @ 12 Noon

You must subscribe to the Project Notes discussion and set notifications for when posts occur
----------------------------------------------------------------

Zoom Shortcut: Alt-Y to raise/lower hand

--------------------------------------------------------------------

Project 1

Binary encoding
- Binary encoding is most easily accomplished using FILE * (file pointer) and fread/fwrite.

- Numbers should not be stored as strings.
  * At least one number stored in binary.

- C++: Use read() and write() after opening using ios::binary; <iostream> & <fstream> 
  > fstream, ifstream, ofstream
- C : Use fread/fwrite after opening with mode "rb+" (or wb or wb+ or ab or ab+); <stdio.h> or <cstdio>
  > FILE*

Makefile: First target

all: p1 createBin printRecs

OR

.PHONY: p1 createBin printRecs

This is fine, as this causes each dependency (which is also a target later in the file) to be evaluated. 
- If any of them are newer than their dependencies, their associated commands will execute.

------------------------------------------
Old Acad Forum

https://acad.kutztown.edu/phpBB3

--------------------------------------------

Shell Execution Notes

Key point: Command does not have access to parent's data space as it is lost upon exec issuance
- Child does retain pid (so wait() or waitpid() in parent still work)

Shell Execution
- Ordinarily, a command in a shell causes the following to occur:
  * A child is forked off
  * The command is executed using an exec command
  * The parent collects the child data via wait().

If the command has  |, then an unnamed pipe must be created to facilitate communication
  ==> pipe ends, which are retained on exec, are no longer accessible unless they are somehow passed during the exec
	- on the command line

<, >, and |:
< : Input redirect		more < abc.txt  - Run more with input redirected from stdin to abc.txt
> : Output redirect		ls > myDir.txt	- Stores output of ls command in file myDir
| : Pipe to another process	ls -l | more    - Sends output of ls -l to more to be paginated
						  ls -l's output is piped to more & 
							more's input is on the read end of that pipe

Simulating the Shell - Note that child opens file. Try this one; Not much different than lsToDir.txt
ls > myDir.txt            
fork the child to run ls
Child:
  outFd=open("myDir.txt",O_WRONLY|O_CREAT,0644)
  // Set the child's stdout to write to the file
  dup2(outFd,1);
  close(outFd);
  execlp("ls","ls",NULL);
Parent wait for child


XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

more < abc.txt
fork child in which to run command
Child:
  inFd=open("abc.txt",O_RDONLY)
  // Set input to more to be from stdin
  dup2(inFd,0);
  // important to close because when ls is done, it will close fd 1, meaning more will get an EOF 
  // 		and know that the text from the incoming command is finished
  close(inFd); 
  execlp("more","more",NULL);
Parent waits for child

XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

ls -l | more  Image: ls_More
Create pipe(pipeFds) - read from pipe is fd 3,  write to pipe is fd 4
fork child for ls
Child:
  // redirect ls's stdout to pipe's write end
  dup2(pipeFds[1] (file descriptor 4),1)
  close both original pipe ends 
  exec("ls","ls","-l","NULL");
fork child for more
  // redirect more's stdin to pipe's read end
  dup2(pipeFds[0] (file descriptor 3),0);
  close both original pipe ends 
  execlp("more","more",NULL);
wait for children

=================================================
To run a command in the background, end it with &
To place a running process in the background, suspend it with ^Z and then enter bg
To resume a suspended process, use fg

Note: Processes are numb ered and can be viewed by entering 

jobs

To resume a specific job, use

fg <job #>

===============================================================
General Notes to Precede the next section

Process - Executing program

A Couple of Definitions Wrt processes
- Parallel: Correspond precisely
- Concurrent: Lifetimes overlap, possibly by as little as a nanosecond


==========================================================
Unix IPC & Synchronization

Communicating Sequential Processes - C.A.R. Hoare
- One of the pre-eminent papers in the history of our discipline.
- Link is on forum

IPC
- Threads are lightweight
  * Use mutex locks to synchronize
- Processes are heavyweight
  * Use semaphores or other constructs (e.g. CCR, monitor) to synchronize