CODEWITHSUNDEEP
cwindowssignals
James Joshua Street
James Joshua Street

Reputation: 3419

how does windows command prompt handle consecutive CTRL + C (SIGINT) signals?

I am running a program from the windows command prompt, and I am getting some weird behavior when I press CTRL C, resume, then CTRL C again.

ctrl C causes the program I am using (icarus verilog) to pause the first time I hit ctrl C. I then type "cont"(an icarus verilog command to continue after being paused) and then it exits that handler and reenters the main loop (I have print statements inside that let me know) it was in the 1st time.

However, the 2nd press of CTRL + C does not hit the SIGINT handler.

I am wondering whether windows interprets a 2nd ctrl C event differently and in fact sends a different signal to the program, or perhaps sends a terminate signal.

I was going to post the main code loop, but i realize I can simplify things for the reader.

this function here:

extern "C" void signals_handler(int)
{
    printf("Inside Signals handler \n");
      schedule_stopped_flag = true;
}

is hit by CTRL C the first time, but not the 2nd time it is called.

It is attached by passing this function pointer in the function:

static void signals_capture(void)
{
      signal(SIGINT, &signals_handler);
}

the documentation of the function "signal" can be seen here: http://www.cplusplus.com/reference/csignal/signal/

There does not appear to be any place within the code where the signal handler is detached.

Upvotes: 0

Views: 1074

Answers (1)

James Joshua Street
James Joshua Street

Reputation: 3419

It appears that you have to reattach the handler after it is activated. I am guessing the operating system is removing it or something, but it wasn't the code I was looking at that deattached it. However, doing as the site below recommends and reatttaching the handler seems to work.

http://www.geeksforgeeks.org/write-a-c-program-that-doesnt-terminate-when-ctrlc-is-pressed/

One slightly bothersome thing is that the documentation: http://en.cppreference.com/w/c/program/signal

states that " If the signal handler is called NOT as a result of abort or raise (in other words, the signal handler is asynchronous), the behavior is undefined if the signal handler calls any function within the standard library, except abort _Exit quick_exit signal with the first argument not being the number of the signal currently handled. "

I take this to mean that since I am calling the signal with first argument being the same number of the currently handled signal, that I should expect undefined behavior. This is slightly bothersome, which makes me wonder if there are any other options. However, for now this seems to work.

Upvotes: 1

Related Questions