CSC209H Lecture 6. Dan Zingaro. February 11, 2015

Similar documents
File Descriptors and Piping

Process Creation in UNIX

Process Management! Goals of this Lecture!

Recitation 8: Tshlab + VM

Operating systems and concurrency - B03

UNIX System Calls. Sys Calls versus Library Func

CSC 1600 Unix Processes. Goals of This Lecture

CS240: Programming in C

Ricardo Rocha. Department of Computer Science Faculty of Sciences University of Porto

Process Management 1

CSCB09: Software Tools and Systems Programming. Bianca Schroeder IC 460

Contents. IPC (Inter-Process Communication) Representation of open files in kernel I/O redirection Anonymous Pipe Named Pipe (FIFO)

Process Management! Goals of this Lecture!

Processes often need to communicate. CSCB09: Software Tools and Systems Programming. Solution: Pipes. Recall: I/O mechanisms in C

Operating Systems. Lecture 06. System Calls (Exec, Open, Read, Write) Inter-process Communication in Unix/Linux (PIPE), Use of PIPE on command line

Announcement (1) sys.skku.edu is now available

Lesson 2. process id = 1000 text data i = 5 pid = 1200

File I/0. Advanced Programming in the UNIX Environment

Week 2 Intro to the Shell with Fork, Exec, Wait. Sarah Diesburg Operating Systems CS 3430

System Programming. Process Control II

CSC209H Lecture 7. Dan Zingaro. February 25, 2015

everything is a file main.c a.out /dev/sda1 /dev/tty2 /proc/cpuinfo file descriptor int

UNIX. Session 2. UNIX processes and forking fork system call exec system call death of process kill fork and I/O using it UNIX.

Unix Processes 1 / 31

Parents and Children

CS 25200: Systems Programming. Lecture 14: Files, Fork, and Pipes

Ricardo Rocha. Department of Computer Science Faculty of Sciences University of Porto

CS240: Programming in C

OS Lab Tutorial 1. Spawning processes Shared memory

CSE 333 SECTION 3. POSIX I/O Functions

CMSC 216 Introduction to Computer Systems Lecture 17 Process Control and System-Level I/O

Unix-Linux 2. Unix is supposed to leave room in the process table for a superuser process that could be used to kill errant processes.

Q & A (1) Where were string literals stored? Virtual Address. SSE2033: System Software Experiment 2 Spring 2016 Jin-Soo Kim

Operating System Structure

CS24: INTRODUCTION TO COMPUTING SYSTEMS. Spring 2018 Lecture 20

CS240: Programming in C

System Programming. Process Control III

CSci 4061 Introduction to Operating Systems. Processes in C/Unix

Processes. Jin-Soo Kim Computer Systems Laboratory Sungkyunkwan University

fork System-Level Function

Princeton University Computer Science 217: Introduction to Programming Systems. Process Management

CITS2002 Systems Programming. Creating a new process using fork() 1 next CITS2002 CITS2002 schedule

Lecture 5. Systems Programming: Unix Processes Creation: fork & exec Process Communication: Pipes

Chapter 3 Processes we will completely ignore threads today

CS 355 Operating Systems. Keeping Track of Processes. When are processes created? Process States 1/26/18. Processes, Unix Processes and System Calls

Princeton University Computer Science 217: Introduction to Programming Systems. Process Management

Princeton University. Computer Science 217: Introduction to Programming Systems. Process Management

Assignment 1. Teaching Assistant: Michalis Pachilakis (

Pipes and FIFOs. Woo-Yeong Jeong Computer Systems Laboratory Sungkyunkwan University

Goals of this Lecture

I/O Management! Goals of this Lecture!

The Shell, System Calls, Processes, and Basic Inter-Process Communication

I/O Management! Goals of this Lecture!

CS Operating Systems Lab 3: UNIX Processes

Processes COMPSCI 386

Operating System Labs. Yuanbin Wu

Processes. Processes (cont d)

Processes: Introduction. CS 241 February 13, 2012

Today. Introduction to Computer Systems /18 243, Fall th Lecture. Control Flow. Altering the Control Flow.

CSE 333 SECTION 3. POSIX I/O Functions

PESIT Bangalore South Campus Hosur road, 1km before Electronic City, Bengaluru -100 Department of Information Sciences and Engineering

CMPS 105 Systems Programming. Prof. Darrell Long E2.371

628 Lecture Notes Week 4

Computer Science 330 Operating Systems Siena College Spring Lab 5: Unix Systems Programming Due: 4:00 PM, Wednesday, February 29, 2012

Section 3: File I/O, JSON, Generics. Meghan Cowan

CSCE 313 Introduction to Computer Systems. Instructor: Dezhen Song

Maria Hybinette, UGA. ! One easy way to communicate is to use files. ! File descriptors. 3 Maria Hybinette, UGA. ! Simple example: who sort

Contents. PA1 review and introduction to PA2. IPC (Inter-Process Communication) Exercise. I/O redirection Pipes FIFOs

ปฏ บ ต การ #3. A Simple Shell Interpreter

Systems Programming. COSC Software Tools. Systems Programming. High-Level vs. Low-Level. High-Level vs. Low-Level.

Processes. Operating System CS 217. Supports virtual machines. Provides services: User Process. User Process. OS Kernel. Hardware

Outline. OS Interface to Devices. System Input/Output. CSCI 4061 Introduction to Operating Systems. System I/O and Files. Instructor: Abhishek Chandra

CSC209H Lecture 5. Dan Zingaro. February 4, 2015

System- Level I/O. Andrew Case. Slides adapted from Jinyang Li, Randy Bryant and Dave O Hallaron

Lecture 23: System-Level I/O

OS COMPONENTS OVERVIEW OF UNIX FILE I/O. CS124 Operating Systems Fall , Lecture 2

Fall 2017 :: CSE 306. File Systems Basics. Nima Honarmand

Lecture files in /home/hwang/cs375/lecture05 on csserver.

Preview. System Call. System Call. System Call. System Call. Library Functions 9/20/2018. System Call

COSC Operating Systems Design, Fall Lecture Note: Unnamed Pipe and Shared Memory. Unnamed Pipes

15-213/ Final Exam Notes Sheet Spring 2013!

CSE 410: Systems Programming

Process Management 1

Windows architecture. user. mode. Env. subsystems. Executive. Device drivers Kernel. kernel. mode HAL. Hardware. Process B. Process C.

CSC209 Fall Karen Reid 1

Pipelines, Forks, and Shell

Exceptional Control Flow Part I

CS 201. Files and I/O. Gerson Robboy Portland State University

Introduction to Processes

518 Lecture Notes Week 3

Layers in a UNIX System. Create a new process. Processes in UNIX. fildescriptors streams pipe(2) labinstructions

Exceptional Control Flow Part I

IC221: Systems Programming 12-Week Written Exam [SOLUTIONS]

CSC 252: Computer Organization Spring 2018: Lecture 19

Recitation Processes, Signals,UNIX error handling

TCSS 422: OPERATING SYSTEMS

CPSC 341 OS & Networks. Processes. Dr. Yingwu Zhu

UNIX System Programming. Overview. 1. A UNIX System. 2. Processes (review) 2.1. Context. Pipes/FIFOs

Operating Systems Lab

Operating Systems. Processes

Transcription:

CSC209H Lecture 6 Dan Zingaro February 11, 2015

Zombie Children (Kerrisk 26.2) As with every other process, a child process terminates with an exit status This exit status is often of interest to the parent who created the child But what happens if the child process terminates before the parent can grab its exit status? The child turns into a zombie process Minimal information about the process is retained When the parent obtains the exit status, the zombie will get removed How does the parent accept the exit status?...

wait (Kerrisk 26.1.1) pid_t wait(int *status); If a child process has terminated, store the exit status in *status and continue Otherwise, block until any child terminates, and then store its status If status is NULL, don t store exit status wait returns the PID of the child process that has terminated, or -1 on error A child can terminate normally or be killed by a signal WIFEXITED tells you if the child terminated normally; use WEXITSTATUS to get the exit status

wait: example (wait.c) #include <unistd.h> #include <stdio.h> #include <stdlib.h> #include <sys/wait.h> int main(void) { pid_t child; int status, exit_status; if ((child = fork()) == 0) { sleep(5); exit(8); wait(&status); if (WIFEXITED(status)) { exit_status = WEXITSTATUS(status); printf("child %d done: %d\n", child, exit_status); return 0;

waitpid (Kerrisk 26.1.2) pid_t waitpid(pid_t pid, int *status, int options); The first parameter allows you to indicate the PID of the child for whom you want to wait To wait for any child, which is what wait does, use -1 If options is 0, waitpid blocks when there is no new child info (like wait) If options is WNOHANG, immediately return 0 if there is no status to obtain (instead of blocking like wait)

waitpid: example (waitpid.c) #include <unistd.h> #include <stdio.h> #include <stdlib.h> #include <sys/wait.h> int main(void) { pid_t child; int status, exit_status; if ((child = fork()) == 0) { sleep(5); exit(8); while (waitpid(child, &status, WNOHANG) == 0) { printf("waiting...\n"); sleep(1); if (WIFEXITED(status)) { exit_status = WEXITSTATUS(status); printf("child %d done: %d\n", child, exit_status); return 0;

Orphan Processes What if a parent dies without waiting for all of its children? These unwaited-for children are called orphan processes Any orphan processes are adopted by a process called init (PID 1) init calls wait on them so that they can terminate and be cleaned up If a long-living parent keeps creating processes but doesn t wait on them, the process table will eventually get full

The exec Family (Kerrisk 27.1-27.2) There are six functions whose names start with exec that are used to overwrite the current process image with a new program They differ only in how they are called, not what they do. Here s one... int execl(const char *path, const char *arg,..., (char*)null); The first parameter, path, is the executable file to run Then come the commandline parameters to pass to path When path runs, those parameters are in argv[0], argv[1],...

Example: execl (execl.c) If successful, the exec functions do not return (they can t the original program is gone!). #include <unistd.h> #include <stdio.h> #include <stdlib.h> int main(void) { printf("before exec\n"); execl("/bin/ls", "ls", "-l", (char *)NULL); perror("execl"); exit(1);

Example: execv (execv.c) execv takes an array of strings instead of multiple arguments (more convenient for building commands at runtime) execlp, execvp: search path (i.e. do not have to provide full path to executable) execle, execve: accept environment variables #include <unistd.h> #include <stdio.h> #include <stdlib.h> int main(void) { char *args[] = {"ls", "-l", NULL; printf("before exec\n"); execv("/bin/ls", args); perror("execv"); exit(1);

Why Exec? Shells can use fork and exec to start new processes Process p waits for keyboard input. You type ls p forks a new process c c uses exec to run ls p waits for c to terminate, then prints a new prompt How do you think the shell can start a process in the background?

Shell Skeleton while (1) // Infinite print_prompt(); read_command(command, parameters); if (fork()) { //Parent wait(&status); else { execve(command, parameters, NULL);

File Descriptors (Kerrisk 4.1) If we open something (e.g. a file) in a process, and then fork, it is also open in the child Open files also stay open across exec... but we have to use file descriptors and low-level file I/O, not C stdio I/O To get a file descriptor (FD), use open...

open and close (Kerrisk 4.3, 4.6) int open(const char *fname, int flags, [mode_t mode]); int close(int fd); Some flags: O_RDONLY, O_WRONLY, O_RDWR (like "rb", "wb" (but without the truncation), and "r+b" to fopen) flags can also include O_CREAT which creates a file if it doesn t exist If O_CREAT is included, mode must be supplied and be set to the permissions used when the file gets created open returns an FD (a positive integer that serves a similar purpose as the FILE * returned by fopen)

read and write (Kerrisk 4.4-4.5) //Returns #bytes actually read, 0 for EOF, -1 for error ssize_t read(int fd, void *buffer, size_t maxbytes); // e.g. char buf[1024]; int num = read(stdin_fileno, buf, 1024); //Returns #bytes actually written, -1 for error ssize_t write(int fd, void *buffer, size_t maxbytes);

File Descriptors and fork (forkfd.c) FD s coming from the same open call share a common file position. int fd; char buf[6]; if ((fd = open("blah", O_RDONLY)) == -1) { perror("open"); exit(1); if (fork() == 0) { read(fd, buf, 6); write(stdout_fileno, buf, 6); else { wait(null); read(fd, buf, 6); write(stdout_fileno, buf, 6); read(fd, buf, 6); write(stdout_fileno, buf, 6); parent child filename "blah" pos 6

File Descriptors and fork... Assume the child closes an FD that it inherits from fork, and then opens the file itself: parent child filename pos filename pos "blah" 6 "blah" 6 Now if the child reads six more bytes: parent child filename pos filename pos "blah" 6 "blah" 12

dup and dup2 (Kerrisk 5.5) int dup(int oldfd); int dup2(int oldfd, int newfd); dup returns a new FD that refers to the same file as oldfd (As with fork) Both FD s share a common file position You have to close both FD s to really close the file Whereas dup chooses the new FD to use, dup2 lets you specify which new FD to use dup2 first closes newfd if it is open

Example: Output Redirection (execl2.c) #include <unistd.h> #include <fcntl.h> #include <stdio.h> #include <stdlib.h> int main(void) { int fd = open("lsout", O_WRONLY O_CREAT, 0600); if (fd == -1) { perror("open"); exit(1); dup2(fd, STDOUT_FILENO); execl("/bin/ls", "ls", "-l", (char *)NULL); perror("execl"); return 1;

Inter-Process Communication After a fork, we have two independent processes They have separate address spaces (most importantly, separate copies of variables) So, the processes can t use variables to communicate They could communicate using files, but coordination is difficult We ll discuss ways for processes to communicate after reading week!