Description
Enter the wonderful world of interÂprocess communications.
Program basic signal exchanges among processes.
Redefine signal handlers within programs.
Remarks
The cchars section in the output of command line $stty Âa provides the list of shortcuts for sending a signal to a process from your terminal. They are systemÂdependent, but most OSes use ctrlÂC for SIGINT and ctrlÂ\ for SIGQUIT.
The masking of signals often results in programs that one does not simply interrupt with a SIGINT. The last resort is to use SIGKILL from a terminal: $kill Â9 <pid_victim>
Exercise 1: First tests with signals
Start by downloading this archive (https://newclasses.nyu.edu/access/content/group/51ce8755Â53814dd5Âbae5Â8ae3b3c862d0/Worksheets/SkeletonÂCode/initÂsigs.tgz) that contains source codes for various short programs. Compile and test them to see:
- if they end by themselves, or if they need to be unlocked using one (or more) SIGINT
- if all the display calls they contain get carried out.
Briefly explain the behavior of each of these miniÂprograms.
Exercise 2: Zombie vs. SIGKILL
Compile the following code (https://newclasses.nyu.edu/access/content/group/51ce8755Â5381Â4dd5bae5Â8ae3b3c862d0/Worksheets/SkeletonÂCode/voodoo.c). This program creates a zombie (a child process whose parent never acknowledges its termination ÂÂ sad, I know).
Observe the output of command $ps u
Try to force the termination of the zombie process with a SIGKILL. What is going on ?
Exercise 3: Pending signals
Write a program called pendingÂsignals that displays whether it has received signals but has yet to deliver them. This program works as follows: it masks SIGINT and SIGQUIT, then sleeps for 5 seconds using the sleep function. Upon awakening, the program should display whether any or both of these signals are pending.
What happens if the program unmasks SIGINT and SIGQUIT before displaying whether they are pending? Explain why.
Exercise 4:     Changing the   default behavior (SIG_IGN)
https://newclasses.nyu.edu/access/lessonbuilder/item/26532808/group/51ce8755-5381-4dd5-bae5-8ae3b3c862d0/Worksheets/Lab%20Worksheet%2003%20-%20Sig…   1/2 10/11/2018        Lab Worksheet 03 – Signals
Write a modification of the previous program called pendingÂsignalsÂ2, where the behavior is redefined so as to ignore a SIGINT or a SIGQUIT.
What happens now if the program unmasks SIGINT and SIGQUIT before displaying whether they are pending? Explain why.
Exercise 5: Changing the default behavior (new routine)
Write a modification of the previous program called pendingÂsignalsÂ3, where the behavior is redefined so as to increment a counter and display the value of this counter when receiving a SIGINT. What is the maximum value that the counter can reach? Will it be reached upon every execution? Justify your answer.
What happens now if the program unmasks SIGINT and SIGQUIT before displaying whether they are pending? Explain why.
Exercise 6: Signal Recognition
Write a program called accountant that keeps count of the number of signals it delivers.
Once launched, accountant waits for signals in a loop. For each delivered signal, it increments two counters: a global counter which sums up all signals, and a counter associated with the value of the delivered signal.
The program ends once it has delivered a number MAX_INTR of SIGINT. It displays all of its statistics: the value of each of its valueÂspecific counters, as well as the value of its global counter.
Exercise 7: Buffering shell commands
Write a program called commandÂsalvo that acts as a buffering layer for your terminal.
Once started, commandÂsalvo sits on top of the shell program and awaits commands entered by the user (you can reuse the skeleton code ” (https://newclasses.nyu.edu/access/content/group/51ce87555381Â4dd5Âbae5Â8ae3b3c862d0/Worksheets/SkeletonÂCode/spyÂincomplete.c)spyÂincomplete.c
(https://newclasses.nyu.edu/access/content/group/51ce8755-5381-4dd5-bae5-
8ae3b3c862d0/Worksheets/Skeleton-Code/spy-incomplete.c)“
(https://newclasses.nyu.edu/access/content/group/51ce8755Â5381Â4dd5Âbae5Â
8ae3b3c862d0/Worksheets/SkeletonÂCode/spyÂincomplete.c) for this purpose). Upon every user command, commandÂsalvo prepares its execution via an execvp call performed in a child process. However, a child does not execute the command immediately after being created. Instead, it waits for a signal from its parent. The parent process waits until NBUF user commands have been entered, and then notifies all its children that they can execute their respective command comcurrently. After launching a command salvo, the parent waits for the completion of all its children before preparing the next salvo