Software Systems Spring 2008 For today, you should have: 1) worked on your project 2) read Chapter 23 of the Cow Book 3) read the handout from Database System Implementation and answer the questions below. 4) done the next problem in the LBoS (Santa Claus) Outline: 0) exam 2 1) Santa Claus 2) database algorithms (reading questions from last time) 3) system programming 4) nonblocking writes For next time you should: 1) work on your project 2) read Tanenbaum I/O Sections 5.1 and 5.2 (questions below) 3) Read the Stevens handout Section 12.5: I/O Multiplexing 4) Optional: the H20 problem from LBoS Exam 2 Results -------------- Fox, goose and corn out of 8 points. C programming out of 24 points. Total = 32. Average = 24. Questions, please come see me. Topics in system-level programming ---------------------------------- 1) signals 2) non-blocking I/O 3) the select system call (I/O multiplexing) Recommended reading: Robert Love, "Linux System Programming" http://wb/ss/handouts/love97linux.pdf W. Richard Stevens, "Advanced Programming in the UNIX Environment" signals ------- UNIX provides a primitive (?) form of interprocess communication called signals. See the signal man page, and the following list of signals: Name Number Description SIGHUP 1 Hangup (POSIX) SIGINT 2 Terminal interrupt (ANSI) SIGQUIT 3 Terminal quit (POSIX) SIGILL 4 Illegal instruction (ANSI) SIGTRAP 5 Trace trap (POSIX) SIGIOT 6 IOT Trap (4.2 BSD) SIGBUS 7 BUS error (4.2 BSD) SIGFPE 8 Floating point exception (ANSI) SIGKILL 9 Kill(can't be caught or ignored) (POSIX) SIGUSR1 10 User defined signal 1 (POSIX) SIGSEGV 11 Invalid memory segment access (ANSI) SIGUSR2 12 User defined signal 2 (POSIX) SIGPIPE 13 Write on a pipe with no reader, Broken pipe (POSIX) SIGALRM 14 Alarm clock (POSIX) SIGTERM 15 Termination (ANSI) SIGSTKFLT 16 Stack fault SIGCHLD 17 Child process has stopped or exited, changed (POSIX) SIGCONT 18 Continue executing, if stopped (POSIX) SIGSTOP 19 Stop executing(can't be caught or ignored) (POSIX) SIGTSTP 20 Terminal stop signal (POSIX) SIGTTIN 21 Background process trying to read, from TTY (POSIX) SIGTTOU 22 Background process trying to write, to TTY (POSIX) SIGURG 23 Urgent condition on socket (4.2 BSD) SIGXCPU 24 CPU limit exceeded (4.2 BSD) SIGXFSZ 25 File size limit exceeded (4.2 BSD) SIGVTALRM 26 Virtual alarm clock (4.2 BSD) SIGPROF 27 Profiling alarm clock (4.2 BSD) SIGWINCH 28 Window size change (4.3 BSD, Sun) SIGIO 29 I/O now possible (4.2 BSD) SIGPWR 30 Power failure restart (System V) Where do signals come from? 1) Generated by one process, sent to another. For example, when you type Ctrl-C in a shell window, the shell process sends SIGINT to the running process. a) kill is a program whose whole reason for being is sending signals. By default, it sends SIGTERM, which the receiving process can catch. With flags, it can send other signals. The -9 flag sends the SIGKILL signal, which can't be caught, and almost always successfully kills the recipient. The only other signal that is commonly sent from the command line is SIGHUP, which originally meant "hangup", but which some applications interpret as "restart yourself" or at least "please re-read your configuration files" 2) The kernel can generate signals a) If a process causes a trap, the trap-handler often sends a signal to the process. b) If a process exceeds some resource allocation, the kernel might send it a signal. c) A process can set an alarm, which causes the kernel to send a SIGALRM signal to the process in the future. d) Some signals, like SIGSTOP and SIGCONT, change the runnable status of a process, so they are really "handled" by the scheduler, not the process. In most cases when the receiving process is rescheduled, it resumes in the appropriate signal-handler, rather than where it left off. Most of the default signal-handlers print an error message and then exit, so the process never resumes. If a signal-handler returns without exiting, the process resumes from where it left off, but in this case you have to write the alarm handler _very_ carefully! Example from the C library documentation http://www.gnu.org/software/libtool/manual/libc/Signal-Handling.html #include #include #include /* This flag controls termination of the main loop. */ volatile sig_atomic_t keep_going = 1; /* The signal handler just clears the flag and re-enables itself. */ void catch_alarm (int sig) { keep_going = 0; signal (sig, catch_alarm); } void do_stuff (void) { puts ("Doing stuff while waiting for alarm...."); } int main (void) { /* Establish a handler for SIGALRM signals. */ signal (SIGALRM, catch_alarm); /* Set an alarm to go off in a little while. */ alarm (2); /* Check the flag once in a while to see when to quit. */ while (keep_going) do_stuff (); return EXIT_SUCCESS; } Nonblocking writes (as opposed to Block Rockin' Beats) ------------------ Read the Stevens handout, pages 363-365 http://wb/ss/handouts/stevens93advio.pdf I've prepared the code from Stevens' Program 12.1 wget http://wb/ss/code/nonblock.tgz tar -xzf nonblock.tgz cd nonblock gcc -o nonblock nonblock.c error.c Now run the experiments from pages 365 and 366. ./nonblock < WarAndPeace.txt > temp.file See if the results look like Stevens' Then try it with the output going to the terminal and the stderr stream going to a file named stderr.out ./nonblock < WarAndPeace.txt 2>stderr.out To see how many times we got EAGAIN, use awk: awk '$3=="-1,"' < stderr.out | wc To see the successful writes: awk '$3!="-1,"' < stderr.out How many times did we have to poll for each successful write? Reading questions ----------------- Tanenbaum Section 5.1 and 5.2 1) What is the difference between a device controller and a device driver? 2) What are the two typical ways of communicating with devices? 3) Explain one advantage of memory-mapped I/O and one advantage of special I/O instructions. 4) What is DMA? It is easy to get DMA confused with memory-mapped I/O. Try to keep them straight! You can skim page 278. 5) What is the least amount of CPU state that has to be saved by the interrupt-handling hardware? Regarding kernel mode, see page 2 of Tanenbaum and these notes. You can skim pages 281-2 to get a sense of why interrupt handling is getting harder for hardware designers. 6) What are the goals of the I/O software? 7) What is the primary drawback of "programmed I/O" (so-named because the I/O is managed by a program running on the CPU, as opposed to other hardware). 8) What is the primary drawback of interrupt-driven I/O? 9) What is the potential limitation of DMA? 10) What other sections in this chapter would you like us to cover?