Programming

Code:

#include <signal.h>

void handler(int sig) {
  int i;
  for( i=0; i<=999999; i++ ) {
  }
  printf("Received signal: %d\n", sig);
}

int main() {
   signal(SIGINT, handler);
   while (1) {
   }
   return 0;
}

When SIGINT is delivered for the first time, shouldn't the handler code be executed and its action default to SIG_DFL of SIGINT so that the next time when SIGINT is delivered it should logically terminate

Its not happening so,

each time a SIGINT is delivered, handler is executing without any problems.

Any thoughts on this ?

Surprisingly

it works as expected in solaris and hp - that is terminate when the second SIGINT is delivered

but not in Linux ( RHEL3 )

Could there be any difference in the signal standards ?

Code:

uname -a
Linux 2.4.21-37a8

Resetting the handler is dumb. That is the original behavior, but during the window between the automatic reset and the reinstallation of the handler, a signal can be lost. So BSD changed signal(). On HP-UX, you can get either behavior by linking with different libraries. Anyway, both behaviors were in use when Posix came along. So, according to the Posix standard: And this is why it also says:

I perfectly agree with the above and have been using that only.

Am just curious to know about the behavior of signal(); and why its behavior is different in different systems.

Is it due to the reason that different libraries are in use ? If so, how to identify them ?

Am confused about this too, there is no guarantee with the older semantics that the signal of same type will not be delivered while the current function block for the signal is being executed.

In that case, there is no reason for it to wait till the function block is executed.

In short, can it be said signal() behavior is undefined - or am I being rude in saying that ?

"Undefined" is a little harsh. It's not like signal() is allowed to whistle dixie or anything. I would use the term "unpredictable". A standard signal() has several attributes each of which must be one of two possible behaviors. I thought that I explained "why":

I would use the term "platform dependent".

Use sigaction() and you will get rewards in this life as well as the next from the Great God Posix.

In Visual C++ you have to reinstall the signal handler in order to catch it again.

I think ' platform dependent ' should be more appropriate.

As I could see the difference when executing the same code in HP, Solaris, RHEL3. - Different behavior

Porter, is this what you meant ?