Why do signals exist?

[vippstar]

What is the purpose of signals and why do they exist in C?
thanks in advance

 

[Walter Roberson]

What is the purpose of signals and why do they exist in C?

That sounds eirily like a class assignment question...

 

[Eric Sosman]

What is the purpose of signals and why do they exist in C?
thanks in advance

Signals are C's model of mechanisms most operating environments
provide to handle two kinds of events: erroneous or exceptional
conditions arising from a program's own actions (for example, when
it divides by zero or dereferences NULL), and interventions from
outside the program (for example, hitting ^C to interrupt it). A
C program can set up "signal handlers," special functions that are
called when these exceptional or external events occur; the handler
can respond to the event in some appropriate way.

The details of exactly how these events arise, are dispatched,
and are processed vary greatly from one O/S to another, so the
C Standard says very little about what really goes on: It doesn't
list all the possible signals, it doesn't say which can be ignored
and which cannot, it doesn't say what happens if a signal handler
tries to resume normal operation after most signals. In a sense,
the Standard's mechanism for signals is mostly a "stub," a plain-
vanilla interface to a realm whose details are mostly outside the
Standard itself. Thus, there is not a lot you can do with signals
in portable C code, because even though the signal() function is
a portable interface, the thing it interfaces with is non-portable.
A program that makes non-trivial use of signals is usually tied
pretty tightly to the specifics of a particular O/S.

 

[santosh]

What is the purpose of signals and why do they exist in C?
thanks in advance

They exist to provide asynchronous notification of events to the
program. The C99 Standard defines six standard signals. Implementations
may define more and almost everything about handling signals is
implementation defined. POSIX provides richer signal support and more
guarantees on behaviour.

See section 7.14 of the Standard.

 

[vippstar]

That sounds eirily like a class assignment question...

Perhaps you'll feel better if you hear that I am a hobby programmer.

 

[vippstar]

Signals are C's model of mechanisms most operating environments
provide to handle two kinds of events: erroneous or exceptional
conditions arising from a program's own actions (for example, when
it divides by zero or dereferences NULL), and interventions from
outside the program (for example, hitting ^C to interrupt it). A
C program can set up "signal handlers," special functions that are
called when these exceptional or external events occur; the handler
can respond to the event in some appropriate way.

The details of exactly how these events arise, are dispatched,
and are processed vary greatly from one O/S to another, so the
C Standard says very little about what really goes on: It doesn't
list all the possible signals, it doesn't say which can be ignored
and which cannot, it doesn't say what happens if a signal handler
tries to resume normal operation after most signals. In a sense,
the Standard's mechanism for signals is mostly a "stub," a plain-
vanilla interface to a realm whose details are mostly outside the
Standard itself. Thus, there is not a lot you can do with signals
in portable C code, because even though the signal() function is
a portable interface, the thing it interfaces with is non-portable.
A program that makes non-trivial use of signals is usually tied
pretty tightly to the specifics of a particular O/S.

Thanks mr Sossman, but I still don't see the reason why ISO C would
need signals.
I understand why a standard like POSIX would need them, but I don't
understand ISOs decision to include them in standard C.
I also think you misunderstood my question, perhaps it was poorly
worded.
I do know what signals are for (as a concept in programming) but I did
not understand the concept behind signals in ISO C, and their use.
Then again, perhaps it was me who misunderstood.

 

[vippstar]

They exist to provide asynchronous notification of events to the
program. The C99 Standard defines six standard signals. Implementations
may define more and almost everything about handling signals is
implementation defined. POSIX provides richer signal support and more
guarantees on behaviour.

See section 7.14 of the Standard.

What greatly annoys me is that I must have signals in mind when
programming in ISO C.
I believe they should not be part of the language and I see no reason
for them to be.
I am also aware of POSIX signals, and it makes sense for such standard
to have signals but not for ISO C.

 

[santosh]

What greatly annoys me is that I must have signals in mind when
programming in ISO C.

You don't have to. You can completely ignore the existence of signals if
you want to. In fact, that's what most small C programs will do. The OS
and your C runtime library will take the default action for any signals
delivered, which usually means termination.

I believe they should not be part of the language and I see no reason
for them to be.

You may have a point.

I am also aware of POSIX signals, and it makes sense for such standard
to have signals but not for ISO C.

As such there is not much that ISO C /does/ define about signals, and
fortunately, it's not something you need to consider if you don't want
to. If you do need to consider signals, you'll very likely find
yourself actual coding to a more elaborate standard like POSIX.

 

[Eric Sosman]

Thanks mr Sossman, but I still don't see the reason why ISO C would
need signals.
I understand why a standard like POSIX would need them, but I don't
understand ISOs decision to include them in standard C.
I also think you misunderstood my question, perhaps it was poorly
worded.
I do know what signals are for (as a concept in programming) but I did
not understand the concept behind signals in ISO C, and their use.
Then again, perhaps it was me who misunderstood.

Since most uses of signals rely on things the C Standard
does not describe, it's reasonable to wonder why the loose
descriptions are there at all. But even though the nature
and the processing of signals are highly system-specific, the
Standard still has reason to say a few things about them. For
example, the Standard describes how signals must behave w.r.t.
sequence points, thus allowing the programmer to rely on the
values of certain variables and warning him to steer clear of
others. The Standard requires that after a signal handler
returns (if it can), the interrupted function proceeds as if
nothing had happened; a signal will not, for example, restart
a loop that was already in progress. This guarantee applies
even if the signal handler calls the interrupted function; thus,
a compiler cannot say "This function calls no others and hence
cannot be called recursively; I'll take shortcuts."

So the Standard needs to talk about signals a little bit,
to constrain their behavior w.r.t. the "base" language and give
the programmer a few tools for dealing with them. Since a bare-
bones notion of signals is already present in the Standard, it
is used in a few convenient places, too: arithmetic overflow may
provoke a signal, abort() is defined in terms of SIGABRT, and
so on. Most of the serious work with signals is outside the
Standard's realm, but the Standard has a need to make a few
minimal specifications anyhow.

If the Standard is a "contract" between the C implementor
and the C programmer, the part about signals is a "treaty"
between the C implementation and the foreign realm called the O/S.

 

[Walter Roberson]

The Standard requires that after a signal handler
returns (if it can), the interrupted function proceeds as if
nothing had happened; a signal will not, for example, restart
a loop that was already in progress. This guarantee applies
even if the signal handler calls the interrupted function; thus,
a compiler cannot say "This function calls no others and hence
cannot be called recursively; I'll take shortcuts."

However, if the signal handler refers to any object with static
storage duration, and the operation is not -writing- to an
object of sig_atomic_type, the interrupted function might not
proceed "as if nothing had happened".

The C89 wording specifically prohibits calling any function in the
standard library and then talks about references to objects with static
storage duration. It seems to me that logically the implication would
be that if the signal handler calls some function that refers to an
object with static storage duration (other than writing
sig_atomic_type) that the behaviour is undefined just as if the
signal handler itself had referred to the prohibitted object;
however the transitivity of the constraint is not explicitly specified
in the C89 wording, so other people might have different interpretations.

 

[Army1987]

Thanks mr Sossman, but I still don't see the reason why ISO C would
need signals.

There is something which can be done in portable C, but it is not much.
For example
#include <signal.h>
#include <stdio.h>
static sig_atomic_t stop = 0;
static void handle(int sig) { stop = 1; }
int main(void)
{
signal(SIGINT, handle);
while (!stop)
puts("AAAAAAAAA!");
puts("Ok, I'll stop it.);
return 0;
}

(Well, the way to send a SIGINT is implementation defined, but so is the
way to cause getchar() to return EOF if stdin is interactive...)

 

[Mark McIntyre]

Thanks mr Sossman, but I still don't see the reason why ISO C would
need signals.

The ISO standard doesn't codify what is *needed* in some absolute sense.
It codifies what the committee members felt was useful enough to
standardise, and what could be standardised without losing usefulness.
Presumably they felt that some standardised handling of signal events
would be useful.

On the other hand, graphics, while very useful, couldn't be standardised
sensibly. On the other other hand, quite possibly if C were being
standardised today then networking would be included, since TCP/IP and
sockets are universal enough. However retrofitting it wouldn't be useful
- its already standardised elsewhere.

 

[Walter Roberson]

On the other hand, graphics, while very useful, couldn't be standardised
sensibly. On the other other hand, quite possibly if C were being
standardised today then networking would be included, since TCP/IP and
sockets are universal enough. However retrofitting it wouldn't be useful
- its already standardised elsewhere.

Standardizing socket call parameters might interfere with
Some Large Well-Known Company's "ability to invovate"; I understand
that a L.W-K.C. has already innovated something incompatible at the
API level with POSIX sockets.

 

[Michal Nazarewicz]

However, if the signal handler refers to any object with static
storage duration, and the operation is not -writing- to an
object of sig_atomic_type, the interrupted function might not
proceed "as if nothing had happened".

A "volatile sig_atomic_t" to be precise.