Why do signals exist?

Discussion in 'C Programming' started by vippstar@gmail.com, Jan 28, 2008.

  1. Guest

    What is the purpose of signals and why do they exist in C?
    thanks in advance
    , Jan 28, 2008
    #1
    1. Advertising

  2. In article <>,
    <> wrote:
    >What is the purpose of signals and why do they exist in C?


    That sounds eirily like a class assignment question...

    --
    So you found your solution
    What will be your last contribution?
    -- Supertramp (Fool's Overture)
    Walter Roberson, Jan 28, 2008
    #2
    1. Advertising

  3. Eric Sosman Guest

    wrote:
    > 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.

    --
    Eric Sosman
    lid
    Eric Sosman, Jan 28, 2008
    #3
  4. santosh Guest

    wrote:

    > 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.
    santosh, Jan 28, 2008
    #4
  5. Guest

    On Jan 28, 8:25 pm, -cnrc.gc.ca (Walter Roberson)
    wrote:
    > In article <>,
    >
    > <> wrote:
    > >What is the purpose of signals and why do they exist in C?

    >
    > That sounds eirily like a class assignment question...

    Perhaps you'll feel better if you hear that I am a hobby programmer.
    , Jan 28, 2008
    #5
  6. Guest

    On Jan 28, 8:34 pm, Eric Sosman <> wrote:
    > wrote:
    > > 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.



    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.
    , Jan 28, 2008
    #6
  7. Guest

    On Jan 28, 8:37 pm, santosh <> wrote:
    > wrote:
    > > 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.


    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.
    , Jan 28, 2008
    #7
  8. santosh Guest

    wrote:

    > On Jan 28, 8:37 pm, santosh <> wrote:
    >> wrote:
    >> > 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.

    >
    > 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.
    santosh, Jan 28, 2008
    #8
  9. Eric Sosman Guest

    wrote:
    > On Jan 28, 8:34 pm, Eric Sosman <> wrote:
    >> wrote:
    >>> 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.

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

    --
    Eric Sosman
    lid
    Eric Sosman, Jan 28, 2008
    #9
  10. In article <>,
    Eric Sosman <> wrote:
    >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.
    --
    "Okay, buzzwords only. Two syllables, tops." -- Laurie Anderson
    Walter Roberson, Jan 28, 2008
    #10
  11. Army1987 Guest

    vippstar wrote:

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


    --
    Army1987 (Replace "NOSPAM" with "email")
    Army1987, Jan 28, 2008
    #11
  12. wrote:
    > On Jan 28, 8:34 pm, Eric Sosman <> wrote:


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

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

    --
    Mark McIntyre

    CLC FAQ <http://c-faq.com/>
    CLC readme: <http://www.ungerhu.com/jxh/clc.welcome.txt>
    Mark McIntyre, Jan 28, 2008
    #12
  13. In article <>,
    Mark McIntyre <> wrote:

    >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.
    --
    So you found your solution
    What will be your last contribution?
    -- Supertramp (Fool's Overture)
    Walter Roberson, Jan 28, 2008
    #13
  14. -cnrc.gc.ca (Walter Roberson) writes:

    > In article <>,
    > Eric Sosman <> wrote:
    >>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".


    A "volatile sig_atomic_t" to be precise.

    --
    Best regards, _ _
    .o. | Liege of Serenly Enlightened Majesty of o' \,=./ `o
    ..o | Computer Science, Michal "mina86" Nazarewicz (o o)
    ooo +--<mina86*tlen.pl>--<jid:mina86*jabber.org>--ooO--(_)--Ooo--
    Michal Nazarewicz, Jan 28, 2008
    #14
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Y.S.
    Replies:
    3
    Views:
    1,010
    strajan
    Sep 17, 2003
  2. LT
    Replies:
    7
    Views:
    2,094
    Phlip
    Jul 25, 2004
  3. Mr. SweatyFinger

    why why why why why

    Mr. SweatyFinger, Nov 28, 2006, in forum: ASP .Net
    Replies:
    4
    Views:
    878
    Mark Rae
    Dec 21, 2006
  4. Mr. SweatyFinger
    Replies:
    2
    Views:
    1,840
    Smokey Grindel
    Dec 2, 2006
  5. Markus Mohr
    Replies:
    7
    Views:
    247
    Thomas 'PointedEars' Lahn
    Nov 28, 2003
Loading...

Share This Page