What is the takeaway from lab 4.1

bfmcneill

I am new to C and fairly new to linux. What is the takeaway from the lab 4.1?

coop

It shows you how many times you can handle particular signals and what order they are handled in.

bfmcneill

so is it queuing up signals 1-64 and then emitting them FIFO?

coop

the signals are sent out in order. How they handled and in what order is controlled by a bunch of factors, such as whether they are "real time" signals (> 32) or not (real time signals can queue up, ordinary signals do not) for example. The exact order they run is a kernel question which has varied with time. The answer is not really completely controlled by any standard.

luisviveropena

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.

GRO 108

Hi @luisviveropena and @coop ,
I'm looking for some help to understand this better as well.

If more than one of a given signal is raised while the process has blocked it, does the process receive it multiple times?

What is the 'process' in this context? Is it the signal script? And how to observe if it's blocked? Is there a way to observe the queue in real time?

Thanks for posting that script @luisviveropena I'd like to dig a bit deeper into signals to improve my understanding, is the office hours video where this was discussed still available anywhere? Do you have a recommendation for extra resources?

Thank you

coop

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.

luisviveropena

Hi @GRO 108 ,

The Office Hours recording are kept for one day only, so that one is gone.

I think it could be useful to search for other "C" codes that does similar things. There are also some code in Python that works with signals as well, that could be easier to read and modify.

Many regards,
Luis.

andrecloudengineer

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.

andrecloudengineer

HI Luis,

I have compiled the signal.c program and ran it. See below stdout.

Please let me know if am doing something wrong.

Kind regards,
Andre

coop

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

andrecloudengineer

Hi Coop,

Thank you for your swift response.

I am equally surprised about my own result lol. I will try it again and let you know the outcome.

Best regards,
Andre