PDA

View Full Version : Signals



Govtcheez
07-02-2002, 09:09 AM
In my C class last term, we learned that UNIX handled various happenings by sending signals (for floating point errors, seg faults, etc.). How does Windows handle these things, and is there any way to catch them from a console program?

Prelude
07-02-2002, 09:40 AM
Signals are standard in C. You assign a function that you write to a signal and when it occurs that function is called, or you can raise the signal yourself and the same thing happens. But it's very easy to screw up, so make sure you understand very well what you're doing before working with signals. Here's one possible use for error recovery:


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

static jmp_buf jmpbuf;

static void handler ( int sig )
{
longjmp ( jmpbuf, sig );
}

int main ( void )
{
int *p = NULL;
(void)signal ( SIGSEGV, handler ); /* Segmentation Violation Signal */
switch ( setjmp ( jmpbuf ) ) {
case 0:
*p = 10;
break;
case SIGSEGV:
printf ( "Segmentation violation..recovery code goes here\n" );
break;
}
return 0;
}

-Prelude

Govtcheez
07-02-2002, 10:11 AM
Are the signal names the same?

That looks different than what we did - we assigned a function as signal handler. Also, we were told that the signal function was unreliable, and to use sigaction instead.

Prelude
07-02-2002, 10:42 AM
You were probably using UNIX specific signal functions. The ISO C standard defines two functions, a type, and several macros for different signals. This is all in signal.h.

>we assigned a function as signal handler
As did I. The second argument to signal is the function to handle the first argument.

>Also, we were told that the signal function was unreliable
Signals in general should be avoided when possible because the problems they can cause are not worth what little gain they offer a program. But they can be useful and sometimes are the best option.

-Prelude

Govtcheez
07-02-2002, 10:50 AM
>As did I. The second argument to signal is the function to handle the first argument.

Right - rereading your code, I see I'm an idiot.

What's the other function specified in ISO C? Is it sigaction?

> the problems they can cause are not worth what little gain they offer a program.

What kinds of problems?

> You were probably using UNIX specific signal functions.

Not AFAIK - the only functions we used for signal handling were signal and sigaction. However, we also used functions like sigprocmask and the like - are those UNIX specific?

Prelude
07-02-2002, 12:10 PM
>What's the other function specified in ISO C?
The two ISO C funtions are raise and signal.

>What kinds of problems?
Signals originally had much to be desired, but since they are based on UNIX, ISO C had to tone them down even more, so they're not very useful. Multiple signals can get lost, even if the program checks all signals the it could still terminate without handling future signals since the signal handler has to reestablish itself as the handler or future signals will be dealt with the the default way, and a few other problems having to do with UNIX and PDP-11 being the base for ISO signal design. So there's no portable way to use signals safely.

>are those UNIX specific?
They aren't standard, so I would have to assume so.

-Prelude

Govtcheez
07-02-2002, 12:11 PM
OK - thanks for clearing that up, Prelude...

seems that most of the problems you talked about would be gone if sigaction was adopted in the standard...

adrianxw
07-02-2002, 12:24 PM
sigaction() and sigprocmask() are included in the POSIX standard, so as such, are not strictly UNIX only. Any POSIX compliant OS should implement them. DEC's VMS for example is POSIX compliant. (I believe the US government requires all tendered software systems to be POSIX compliant - perhaps someone could confirm or deny that).

Windows is not strictly POSIX compliant although many of the same concepts are implemented in a variety of more or less subtle variations.

Authors wishing to read up on POSIX and POSIX compliance should have a look at the book "POSIX Programmers Guide" by Donald Lewine. The POSIX threading model, (often called pThreads), is well covered by "Programming with POSIX threads" by Dave Butenhof, and the POSIX 4 realtime extensions by Bill Gallmeisters "POSIX.4".

ober
07-02-2002, 12:27 PM
Govt... I'm not sure who you had, but Vineyard taught us strictly UNIX C... mainly because that's what we used to write the programs, but there was a lot of emphasis put on the UNIX-specific material.

And I hate him for this because there's a ton of stuff I'd love to do but have to relearn it in C because I can't use some of the UNIX stuff.

Govtcheez
07-02-2002, 12:30 PM
> Govt... I'm not sure who you had, but Vineyard taught us

Good call... He always said that it was a class to teach you the structure of UNIX environments (Solaris, in this case), and not C... It always seemed to me that it was the other way around - C with a bit of UNIX.

Regardless, thanks everyone for input - maybe I'll check out those books if I'm having trouble sleeping, adrian.