What is the takeaway from lab 4.1

Hi @bfmcneill ,

I used this small piece of code to make a test on a web session:

#include <stdio.h>
#include <unistd.h>
#include <signal.h>

/* This is a test that shows that a signal 2 (SIGINT can be
handled. So, first CTRL+C it gives a message, then second
time it receives it, the program is terminated.
*/

void my_signal_interrupt(int sig)
{
  printf("I got signal %d\n", sig);
  (void) signal(SIGINT, SIG_DFL);
}

int main()
{
  (void) signal(SIGINT,my_signal_interrupt);

  while(1) {
      printf("Waiting for interruption...\n");
      sleep(1);
  }
}

So you can put that into a file, let's say signal_int.c and them compile it: gcc signal_int.c -o signal_int . Then run it: ./signal_int . Once it's running, on the same terminal hit CTRL+C once, and then a second time; on the second time the program will be terminated. It's a very simple test, of course.

Regards,
Luis.

The process is whichever program to which the signal is being sent, which may or not be the process sending the signal (yes, a process can kill itself which is what you do whenever you hit Ctl-C for example)

There is only one way to see what signals may be pending or blocked that i know of. Looc at /proc/[pid]/status and look at the bit mask of fields such as SigPnd and SigBlk etc, where for pid you put in some pid (you can also look at /proc/self/status where self is the current process. It's a little too much work to deciper the bit mask in this course, but have fun figuring out. This pseudofile has other information for the curious.

Hi Luis and Coop.

Good morning to you both and thank you for your explanation. However, I am still a bit confuse as to how to compile it and run the signal. c programme on my virtual machine.

you need to run "signal" not "signal.c" which is the source. Just do ./signal. Although I am mystified why you get the result you do