Signal Default Action - High Level Programming

matrixmadhan · #1 11-27-2007

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 ?

matrixmadhan · #2 11-27-2007

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

Perderabo · #3 11-27-2007

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:

Quote:

When a signal occurs, and func points to a function, it is implementation-defined whether the equivalent of a:
signal(sig, SIG_DFL);

is executed or the implementation prevents some implementation-defined set of signals (at least including sig) from occurring until the current signal handling has completed. (If the value of sig is SIGILL, the implementation may alternatively define that no action is taken.)

And this is why it also says:

Quote:

The sigaction() function provides a more comprehensive and reliable mechanism for controlling signals; new applications should use sigaction() rather than signal().

matrixmadhan · #4 11-27-2007

Quote:

The sigaction() function provides a more comprehensive and reliable mechanism for controlling signals; new applications should use sigaction() rather than signal().

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 ?

Quote:

from occurring until the current signal handling has completed

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 ?

Perderabo · #5 11-27-2007

Quote:

Originally Posted by matrixmadhan

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":

Quote:

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().

porter · #6 11-27-2007

Quote:

Originally Posted by Perderabo

I would use the term "unpredictable".

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.

matrixmadhan · #7 11-27-2007

Quote:

I would use the term "platform dependent".

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 ?

More UNIX and Linux Forum Topics You Might Find Helpful
Thread	Thread Starter	Forum	Replies	Last Post
CEP: What about the action?	iBot	Complex Event Processing RSS News	0	02-15-2008 08:20 AM
tracking user action	xitrum	UNIX for Advanced & Expert Users	7	03-07-2007 01:48 PM
action command	esham	Shell Programming and Scripting	5	07-30-2005 01:04 AM
action based on rsync status	dangral	UNIX for Dummies Questions & Answers	2	04-29-2005 09:25 AM
any idea to repeat a action in VI	myelvis	UNIX for Dummies Questions & Answers	6	11-26-2003 03:21 AM

Thread Tools	Search this Thread
Show Printable Version Email this Page	Search this Thread: Advanced Search
Display Modes
Linear Mode Switch to Hybrid Mode Switch to Threaded Mode