CS 3377 exam 2

pipe(int ), where int is an array of 2 ints to hold file descriptors that will be associated with the pipe.

-fd[0] is the read fd.

-fd[1] is the write fd

-3, 4. Chooses minimum available fd; recall 0-2 are taken by standard input, output, and error.

Both parent and child can access both ends. Remember file descriptors for parent and child lead to the same destinations; one for pipe read, another for pipe write.

One pipe from parent to child; another from child to parent. After forking, close the end which the parent/ child respectively won’t use.

-Dup(fd) takes the fd, and opens the lowest numbered available next fd to have the same destination as the given fd. (In this case, you want 0-2)

-dup2(fd, destination) takes the fd, and replaces the destination fd to point to point to the same location as the fd you specified.

-In the case any remaining fds are pipes, you would cause a hangup of the parent. (For ex, a perpetually open pipe write end). Thus, you should closed unused fds.

*Note: both dup/dup2 return the newly created/ replaced fd. [-1 for error]

Will block until something gets read. If the write end is closed, whatever’s left in the pipe will be read, and when that’s exhausted, you hit eof and stop being able to read things in.

This is critical to get eof-dependent processes to terminate (instead of having them get blocked at a read and run forever). Thus, why you should close unused pipe ends, so when the active write and is finished, you can close it and the process on the other end knows to stop.

Execl - takes a pathname (can be relative, which is when you just type the filename), and most importantly, argv passed one by one as C-strings (with first being program name).

Execvp - uses PATH to find the file and assumes you pass a pointer to an argv C-string (pointer) array you already constructed.

-argv[argc] must be NULL. For execvp, consider how the exec function would know how man pointers in argv otherwise.

-e lists all processes

-f gives pid, ppid, user, start time, and more details.

-ps output fields are formatted and aligned, not space delimited

-p specify a process to get information on

-u list’s a user’s processes.

touch scripFile, so then you can chmod ugo+x scriptFile to it. Execute is not by default on.

First line is: #! /bin/bash

Which tells bash to execute. (changing the second item will change what executers the script -- for instance, Python is an option).

struct Name {

// entries

};

and for variables:

struct Name varl;

or list them after closing brace of struct.

-Programs use library functions

-Scripts use the shell and its commands

(convenient to give tedious command sequences to a computer to do); they’re not very powerful alone.

Provides options for places to search for files. (You have to use ./script because your path is set to search in ~veerasam/bin if not found in your directory.)

-Both involve a call to executable name with (optional) arguments.

-scripts is interpreted, program is compiled.

-script is mostly just text stored in file, program binary is much larger.

variable = [what you want to assign] to access, must reference as $variable

Creates a separate process, executes the commands inside the backticks, and the results of those commands are assigned to the shell variables.

You can assign characters, strings, or numbers. There is no explicitly enforced typing, although is the contents are wrong, tour scripts might run into errors. In a sense, it’s like the shell dumps the contents of the variable as a string wherever the variable is used and then interprets that expanded line and determines if it can execute or not.

$1, $2, … for individual (technically ${1}, ${2}, … is more correct when arguments get into double digits), or $* for all.

Printout every line of what the shell script executed, for debugging.

if [condition]

then

execute if true

else # optional

execute if false

if #marks end of if. MANDATORY

Between two values:

-ne not equal

-eq equal

-lt less than

-le less than or equal

-gt greater than

-ge greater than or equal

-z [String] tests if String is zero length.

condition sits inside [ condition ] - must have left/right spaces. For the between two values, left and right side must evaluate to a comparable value.

!! = last expression typed into command line replaces this

$$ = pid of calling process replaces it

$LOGNAME contains your login name

‘ expr [expression]’, but since this is a command you must be careful to escape any special meaning symbols. You will also need to refer to variable contents as $var. ((expression)) requires assignment inside parentheses, but any group of letters here between operators is assumed to be taken as a variable. ($var is optional).

finger takes an argument of a username and prints out info about the user.

diff takes two files as arguments and finds the differences. To read diff’s output, < indicates unique to left file, > indicates unique to right file.

read variableToReadInto

Note it reads lines at a time

while [ condition ]

do # to do if valid

done # MANDATORY

for { shell variable ] in $var do #to do for each token split by space

done # MANDATORY

for ((var=init; [condition];

[update var]))

do# to do on each iteration

done #MANDATORY

Syntax is very close to C

popen allows you to specify a program to exec and what to do with a pipe program (i.e. five it input, take its output). it gives a FILE*.

pclose that FILE* to close the pipe

-Exist independently of programs

-Don’t have to be passed on from a common ancestor. Just need to know name to use

p

0, it’s just a buffer

mkfifo(C-string name, octal permissions)

then chmod(C-string name, octal permissions)

-In the examples, the permissions in mkfifo didn’t work properly

1 reader, many writers. Too many readers is a bad idea as read side isn’t atomic but write side is.

Gets the USER environment variable (login name)

Make children that interact with clients, so they can get stuck.

Otherwise they become a separate server. leading to multiple readers in a FIFO.

For a child of the server, and create a new FIFO in the child to talk to that client. Like a bank: general queue for service (parent that assigns each client to a child), then particular employee to handle your case (child).

What’s written may get stuck in the buffer instead of written to the FIFO, fflush ensures that data is written. (For a deeper look, fprintf looks at the file type, and it unfortunately thinks FIFOs are a larger file so a large buffer is ideal.)

1. server blocks until the write end opened at least by one client

2. Client blocks until the read end opened by the server

3. Writing to a closed read-end FIFO will crash the program. (Same for regular pipes.)

4. The remaining data in pipes is read out, then EOF is read.

5. Read blocks until data is written

1. pauses foreground process and lets you interact with shell

2. puts background job id into foreground

3. Puts foreground job id into background

4. starts a job in the background

-Share: global memory, file descriptors, code executable

-don’t share: registers/ stacks

-A thread is a part of a process, so shares the PID

-To give it an identification, threads get a lightweight process ID instead

-A fork creates a brand new process

Show you LWP (lightweight process id) and NLWP (num of lightweight processes) aka thread pid and number of threads

-Threads can be assigned to different cores

-A regular program is serialized and executes on one core

-Clearly, using all the cores in parallel is faster

-1 thread. The program execution itself is a thread

List details about server CPUs

Master thread assigns tasks to the other threads

Threads are given execution time by the system scheduler. Without synchronization, the order is unpredicable

void functionName (void args)

Must be void *

pthread_t

(pointer to a pthread_t, optional thread attributes [we use NULL], startup function, pointer to function arguments)

-Important note: the function arguments must be accessible from the one pointer, and can be NULL

Changes: Returns 0 on success, and the pthread_t that is pointed at is populated with thread info

(pointer to pthread_t type, pointer to location to store return value)

-calling thread is blocked until specified thread returns

-location to store return value is populated with return value

Asynchronous threads try to update a counter variable. Consider if thread A reads the counter, then thread B reads the counter before A increments it. Then, thread A updates the counter. However, since thread B has old data, when it increments what is read and updates the counter, it writes the same value thread A just wrote, with net effect wasting an increment. (Hence why the observed values could never exceed the expected count).

Can create a mutex statically with:

pthread_mutex_t name = PTHREAD_MUTEX_INITIALIZER;

Call the lock/unlock functions with a pointer to the mutex (struct).

Problem: Threads expecting to update the most recent copy of shared data can instead read in an old value before another thread that read earlier has had time to update it.

Solution: Surround the problem code with a mutex lock/unlock. When a thread locks the mutex, it can enter that code segment. Other threads trying to enter the portion can’t lock the mutex, so they block outside that portion. The thread that enters does its job, then unlocks the mutex. Now, another thread can lock the mutex, enter the code segment, and do its job. There are no pending writes when an entering thread reads (assuming read/write are contained in the mutex-ed segment).

Removes a specified filename, thus decreasing its number of inode links (which usually leads to a remove if the file only had one).

Any threads that are part of the overall process.

a. Sends SIGTERM (15) to processes with pid 12345 23813

b. sends SIGKILL (9) to the process group under job id %1

c. Sends SIGSUR1 to the process group under job ids %3, %5, and pid 2213

d. The kill command’s single option takes either the signal number or signal name (signal constants are of form SIG[NAME]) For example, kill -9 … and kill -KILL … are the same.

a. kills the process. Cannot be ignored or handled. The program “emergency kill switch.”

b. Tells process to terminate; process may or may not depending on if it handles the signal.

c. Prevents processes in background process groups from reading terminal input.

d. Tells shell to clean up processes after you disconnect.

e. From writing into a pipe/fifo with no reader. (this cause your program to terminate!)

f. Segmentation fault

g. When the alarm from the alarm function is up.

h. User defined signals that we used in the race programs

i. aka ctrl+c, interrupts, and if unhandled, quits the program

j. ctrl+z, stops the foreground processes unless handled

k. Emergency stop, cannot be ignored or handled

First parameter is signal constant, second is function call to handle, which must take an int argument with void return. (Return is pointer to old function it was calling to handle the signal, but that’s not important).

Call the signal function reestablishing the handler, inside the handler itself. (There is a slight issue: if the same signal happens before the handler is reestablished, the program does its default action, which is usually to quit. Not a big deal for this class.)

Single parameter is the number of seconds until it generates SIGALARM for you.

1. program stops normal execution

2. Program enters signal handler

3. Once handled, resumes in exact location the program left off executing

They’re ints; serve as IPC before pipes

signal.h

pthread.h

Lets you execute one, then the next, in sequence

User creates the process, and receives notice of process termination. It’s loaded into main memory and waits for execution. If the CPU is bust, it might get swapped into the disk. When the CPU is ready, the process runs. Perhaps it hits a pipe read while waiting for the other end to write, and becomes blocked. If this takes too long, it may also be swapped into the disk to free main memory for other processes.

First argument is pid to target, and second is signal number (or signal name constant) to send

the foreground process group (i.e. current process running in the foreground and all its children).

S = interruptible sleep (those that a signal can wake it from)

R = running

D = uninterruptible sleep (disk io)

T = Stopped process (ctrl+Z)

Z = zombie, aka finished child process waiting for parent to get its data

ps -lf (little l) displays

CPU execution time; the higher counter was probably processed for longer (the “winner”).

Sending a SIGSUR1 started the race; SIGSUR2 ended the race

It’s undefined who gets the input. They might alternate, or one might get more of the input. You don’t know who will receive your input.

No, the shell resumes and prevents the children from getting input (In theory, but very buggy in practice.)

(what really happens is that the shell and parent process are in different process groups. When the parent dies, the shell’s process group comes to the foreground and the OS prevents background process groups from reading io.)

-The waiting while loops wasted CPU time doing nothing

-Semaphores are “OS flags” that can put waiting processes to sleepA

-Inherited from the parent, since it’s guaranteed those handlers still exist.

-Reset, since there is no guarantee old signal handlers exist in the new program.

-Threads share the signal handlers; when one sets it, all use that

Takes: (buffer to read into, size of object, number of objects, FILE*)

returns: num of objects read

takes: (int fd, buffer, number of bytes to read)

returns: number of bytes

takes: (buffer to write from, size of objectt, number of objects, FILE*)

returns: number of objects written

takes: (int fd, buffer, number of bytes to write)

returns: number of bytes written

takes: (filename, use mode string)

returns: FILE* to file, or NULL on error

takes: (FILE* of file)

returns: 0 on success, EOF on failure

takes: (file name buffer, flags, optional mode [permissions])

returns: int fd, or -1 on error

takes: (int fd)

returns: 0 on success, -1 on error

sys/socket.h (sockets themselves)

arpa/inet.h (utilities)

nettinet/in.h (for ip address structures)

IP Address: gives an ID/address to a machine (servers, gateways - machines that forward your information, etc) over the internet (or intranet).

Port: A machine may have multiple, allowing it to do many different network services each on a different port.

Together, they form an end point.

Create socket

Bind socket (may require finding IP address/port)

Listen for clients

Accept a client

Send/ receive messages

Close socket for client when done

Create socket

Connect to server (part of this step may involve getting IP address/port)

Send/ receive messages

Close socket for client when done

UDP: messages are sent without verification they received.

TCP: Three way handshake before any messages are sent to verify the connection. (Also has more steps as a result). We use TCP

65,536 of them

-Data in packets used by network applications/services

-information used by TCP/UDP

-Contains IP address and relevant information

-Gets message onto open internet (ethernets, NICs, MAC addresses that service many devices)

-Actual wires

socket will use IPv4 protocol (“internet” right now)

1. We use IPv4, so specify IPv4 using constant AF_INET

2. To get the IP address, assign htonl(INADDR_ANY) - conceptually, INADDR_ANY is the IP address of the current machine.*

3. Port number to use, via htons(port # desired)

htons and htonl convert 16-bit/32-bit integers, respectively, to network byte order. (i.e. standardized form that the internet requires).

*It's a little more complicated in reality. Technically, it's saying assume all the IP addresses the machine owns.

Takes (buffer address, character, size), and sets size bytes to the character specified starting at the buffer address

(type of IP address (AF_INET for us), type of socket (SOCK_STREAM - the TCP socket for us), protocol (leave 0))

returns socket descriptor (which is just another fd) or -1 for error

(socket fd, pointer to sockaddr (sockaddr_in compatible as well) structure, size of that structure)

Returns 0 normally, -1 on failure.

- Sockaddr specifies IP address the machine doesn't have.

- Sockaddr specifies port that is already occupied.

Pass it (socket fd, number of requests to queue). Returns 0 on success, -1 on failure. Allows requests to be passed into the socket.

(socket fd, pointer to sockaddr struct [sockaddr_in is compatible], length of that structure)

0 for success, -1 for failure. Opens connection to the server address specified in the struct. Also binds the client socket to an available address/port.

(server's socket fd, sockaddr pointer [if you want client info, otherwise pass NULL], ptr to length of that buffer [NULL for us])

Returns a socket descriptor that allows communication with client.