<signal.h> - question about signals

Discussion in 'C Programming' started by Jackie, Jul 28, 2004.

  1. Jackie

    Jackie Guest

    Hi everyone,
    I'd like to know when and how signals are used (e.g. SIGFPE, SIGABRT,
    SIGTERM, SIGSEGV, SIGINT)? Thank you so much.
    Jackie, Jul 28, 2004
    #1
    1. Advertising

  2. Jackie

    Ganesh Guest

    "Jackie" <> wrote in message news:<l_GNc.962$>...
    > Hi everyone,


    Hello!

    > I'd like to know when and how signals are used (e.g. SIGFPE, SIGABRT,
    > SIGTERM, SIGSEGV, SIGINT)? Thank you so much.


    Signals provide a way to handle asynchronous (and unexpected) events.
    A signal (number) is associated with an event. Like:

    SIGFPE: associated with the event "Floating Point Error (FPE)". For
    example: This occurs when the process tries to divide a number by zero
    as in p=5/0.

    SIGSEGV: associated with the event "Segment Violation". Is generated
    when the process tries to access an illegal memory segment (this is a
    common error with pointers).

    SIGINT: This is generated by the terminal (console) when the terminals
    interrupt key (usually Ctrl+C) is pressed.

    Every signal has an associated default action, that takes place when
    the signal is generated. But this can be changed using one of the
    signal functions (like signal(), sigaction()). These functions allow
    us to specify a user defined action (function) for handling a signal.
    Now after installing our own handler, if the signal occurs.. This time
    the user specified action will be taken to handle that signal.

    However there are some signals which cannot be caught and handled...
    Like: SIGKILL, SIGSTOP.

    Plzz refer to ur systems manual for more information...

    - Gana
    Ganesh, Jul 28, 2004
    #2
    1. Advertising

  3. Jackie

    Jackie Guest


    > Signals provide a way to handle asynchronous (and unexpected) events.
    > A signal (number) is associated with an event. Like:
    >
    > SIGFPE: associated with the event "Floating Point Error (FPE)". For
    > example: This occurs when the process tries to divide a number by zero
    > as in p=5/0.


    Thank you so much for replying. Can you give me a code example that shows
    how one may be able to use the signals in <signal.h> to handle asynchronous
    (and unexpected) events? Should I call this function: "int raise(int sig)"?
    I very much like to know how to use signals in a c code since the signals
    are mentioned in the standard library.
    Jackie, Jul 28, 2004
    #3
  4. Jackie

    kal Guest

    "Jackie" <> wrote in message news:<toLNc.1067$>...

    > Thank you so much for replying. Can you give me a code example that shows
    > how one may be able to use the signals in <signal.h> to handle asynchronous
    > (and unexpected) events? Should I call this function: "int raise(int sig)"?
    > I very much like to know how to use signals in a c code since the signals
    > are mentioned in the standard library.


    That confuses me a lot too. Even the function prototype
    takes a while to figure out.

    Let us see now.

    void (*signal(int sig, void (*func)(int)))(int);

    singal is a function taking two parameters and teturning
    a pointer to a function.

    The paramters are (1) an int, and (2) a pointer to a
    function taking an int and returning nothing.

    The return value is a pointer to a function taking an int
    and returning nothing.

    Does this seem ok?

    Now, how do I declare a pointer to this signal function?
    kal, Jul 28, 2004
    #4
  5. In article <l_GNc.962$>,
    Jackie <> wrote:
    >Hi everyone,
    >I'd like to know when and how signals are used (e.g. SIGFPE, SIGABRT,
    >SIGTERM, SIGSEGV, SIGINT)? Thank you so much.


    They're typically raised by the system to indicate asynchronous events
    that your program might be interested in. (You can also raise them
    synchronously by calling raise(), which has the effect of invoking the
    appropriate signal handler for the signal number you give it.)

    When a signal is raised, the handler for that signal gets invoked; you
    can install a signal handler to do something you want done when a signal
    is raised. There's not much that you can depend on being able to do
    in a signal handler, so usually the best way to do things is to set a
    flag that your program checks occasionally and does appropriate things
    (and then clears it) if it finds that it's set.

    SIGFPE, SIGSEGV, and SIGILL are only raised after your program has somehow
    invoked undefined behavior, so if your system supports it you can catch
    these and your signal handler can find and attempt to fix the source of
    the problem.

    SIGABRT indicates an abnormal termination. (This is raised by calling
    abort(), which fgets called for assert failures.) Trapping this would
    be useful for, f'rexample, dumping post-mortem debugging information if
    you run into an internal error.
    (If it's raised as a result of calling abort(), it's considered a
    synchronous signal, so you can call any library function other than
    raise(). It's not immediately clear to me whether you're allowed to call
    abort() again (which would apparently call raise() again), but it's also
    not clear why you would want to.)

    That leaves SIGINT and SIGTERM, for interactive attention requests and
    termination requests, as the only ones that are really portably useful
    in a working program[1]. Typically, if you're doing a long-running
    computation that you want to be able to interrupt (to change the
    parameters or provide additional input - if you want the program to be
    able to run when the user doesn't have anything to say, this is a good way
    to work around the fact that any stdio input will wait until there's input
    there) or that needs to be able to be shut down cleanly in the middle of
    a run, you'd install handlers that set an appropriate flag, and check the
    flags and act appropriately at some appropriate point in your computation.
    Here's an (oversimplified) example program of how you might want to
    use them:
    --------
    /*Example of using SIGINT and SIGTERM in a program with a long-running
    computation
    Not compiled or tested, for instructional use only, standard disclaimers
    apply
    Written by Dave Vandervies 2004-07-28 to be used, abused, bent, folded,
    or mutilated as appropriate.
    */

    /*Alphabetical: the One True Order for #including standard headers.*/
    #include <errno.h>
    #include <limits.h>
    #include <signal.h>
    #include <stdio.h>
    #include <stdlib.h>

    volatile sig_atomic_t stop;
    volatile sig_atomic_t interrupt;

    void sighandler(int signum)
    {
    if(signum==SIGINT)
    interrupt=1;
    if(signum==SIGTERM)
    stop=1;

    /*Calling signal like this is specifically permitted (N869 7.14.1.1#5,
    see also #4); whether it's needed is implementation-defined (N869
    7.14.1.1#3).
    */
    signal(signum,sighandler);
    }

    int do_long_computation(void)
    {
    unsigned long i,j;
    for(i=0;i<ULONG_MAX;i++)
    {
    for(j=0;j<ULONG_MAX;j++)
    {
    if(stop)
    {
    printf("Termination request received, exiting (i=%lu, j=%lu)\n",i,j);
    /*If we have any cleanup to do (saving a checkpoint file,
    perhaps), we do it here
    */
    return 1;
    }
    if(interrupt)
    {
    char buf[64];
    unsigned long new_val;

    printf("i=%lu, j=%lu\n",i,j);
    fputs("You wanted a new value for i? Enter it now: ",stdout)
    fflush(stdout);
    fgets(buf,sizeof buf,stdin);
    errno=0;
    new_val=strtol(buf,NULL,0);
    if(new_val==ULONG_MAX && errno==ERANGE)
    puts("Invalid value, using old value");
    else
    i=new_val;

    interrupt=0;
    }

    /*Do a part of the long computation here*/

    }
    }

    return 0;
    }

    int main(void)
    {
    /*Pointer to function of the appropriate type for a signal handler.
    We use this to check the return value of signal() against multiple
    possible returns.
    */
    void (*oldhandler)(int);

    /*Start by installing the appropriate signal handlers (we want to do
    this before we get into anything nontrivial; if we had enough setup
    to justify a separate "initialize" function this would go there)
    */

    /*This is, I'm told, the safe way to install a SIGINT handler on unix-
    like systems (so that an interrupt from the terminal interrupts the
    foreground program as the user expects and not something running in
    the background), and does no harm elsewhere.
    */
    /*signal() returns the old handler for this signal, or SIG_ERR on
    failure.
    */
    oldhandler=signal(SIGINT,sighandler);
    if(oldhandler==SIG_IGN)
    {
    puts("SIGINT was ignored (perhaps we're in the background?), re-ignoring\n");
    signal(SIGINT,SIG_IGN);
    }
    else if(oldhandler==SIG_ERR)
    {
    fputs("Unable to install handler for SIGINT, running in uninterruptible mode\n",stderr);
    }

    /*Since we're only checking against SIG_ERR here, we can use the return
    value of signal() directly
    */
    if(signal(SIGTERM,sighandler)==SIG_ERR)
    {
    fputs("Unable to install handler for SIGTERM, left with system default\n (this may cause an unclean shutdown)\n",stderr);
    }


    /*Now that we've got our signal handlers installed, we can start our
    long computation secure in the knowledge that the user can cleanly
    interrupt it (usually ^C on commonly used interactive platforms) or
    terminate it (in a system-dependent manner), or at least has been
    warned that attempting to do so won't work.
    */
    if(do_long_computation())
    {
    /*Nonzero return indicates early interruption, so indicate that with
    exit status
    */
    return EXIT_FAILURE;
    }

    return EXIT_SUCCESS;
    }
    --------


    dave

    [1] This is actually a slight stretch, since an implementation that isn't
    attempting to provide nonzero QOI can legally implement the signal
    handling code as:
    --------
    void SIG_DFL(int i) {}
    void SIG_IGN(int i) {}
    void SIG_ERR(int i) {}

    void (*signal(int signum,void (*handler)(int)))(int)
    {
    /*SIG_IGN is the only signal handler we can install without an error*/
    if(handler!=SIG_IGN)
    return SIG_ERR;
    else
    /*We know the previous handler was SIG_IGN*/
    return SIG_IGN;
    }

    int raise(int signum)
    {
    /*We know the handler is SIG_IGN, so the as-if rule says we can
    get away with doing nothing here.
    Return value of 0 means we successfully did nothing.
    */
    return 0;
    }
    --------
    But you're not likely to encounter implementations that attempt to be
    useful and don't support signals, unless the underlying system doesn't
    provide a way to implement them or makes it pathologically difficult.

    --
    Dave Vandervies
    I'm not sure how I can describe it so as to be free from the possibility of
    perverse interpretation; ultimately, communication can only occur between
    people who want to communicate. --Anton van Straaten in comp.lang.scheme
    Dave Vandervies, Jul 28, 2004
    #5
  6. In article <>,
    kal <> wrote:
    >"Jackie" <> wrote in message
    >news:<toLNc.1067$>...
    >
    >> Thank you so much for replying. Can you give me a code example that shows
    >> how one may be able to use the signals in <signal.h> to handle asynchronous
    >> (and unexpected) events? Should I call this function: "int raise(int sig)"?


    raise() lets you synchronously raise a signal within your program, and
    is approximately equivalent to calling the appropriate function directly
    (but knowing what the currently installed handler for the signal is
    may be nontrivial). It's not needed if you're receiving asynchronous
    signals generated outside your program.

    >> I very much like to know how to use signals in a c code since the signals
    >> are mentioned in the standard library.

    >
    >That confuses me a lot too. Even the function prototype
    >takes a while to figure out.
    >
    >Let us see now.
    >
    >void (*signal(int sig, void (*func)(int)))(int);
    >
    >singal is a function taking two parameters and teturning
    >a pointer to a function.
    >
    >The paramters are (1) an int, and (2) a pointer to a
    >function taking an int and returning nothing.
    >
    >The return value is a pointer to a function taking an int
    >and returning nothing.
    >
    >Does this seem ok?


    Yep. The "function taking an int and returning nothing" part is the
    signal handler type; you give it a pointer to the new signal handler,
    and it returns a pointer to the old signal handler (or SIG_ERR, a special
    value of the appropriate type that indicates a failure).


    >Now, how do I declare a pointer to this signal function?


    Use typedef.

    typedef void (*sighandler_t)(int);
    sighandler_t (*pointer_to_signal_function)(int,sighandler_t) = signal;

    (But why would you want to, unless you're trying to wrap your brain
    around function pointers?)


    dave

    --
    Dave Vandervies
    I'm not sure how I can describe it so as to be free from the possibility of
    perverse interpretation; ultimately, communication can only occur between
    people who want to communicate. --Anton van Straaten in comp.lang.scheme
    Dave Vandervies, Jul 28, 2004
    #6
  7. Jackie

    Ganesh Guest

    "Jackie" <> wrote in message news:<toLNc.1067$>...
    > > Signals provide a way to handle asynchronous (and unexpected) events.
    > > A signal (number) is associated with an event. Like:
    > >
    > > SIGFPE: associated with the event "Floating Point Error (FPE)". For
    > > example: This occurs when the process tries to divide a number by zero
    > > as in p=5/0.

    >
    > Thank you so much for replying. Can you give me a code example that shows
    > how one may be able to use the signals in <signal.h> to handle asynchronous
    > (and unexpected) events? Should I call this function: "int raise(int sig)"?
    > I very much like to know how to use signals in a c code since the signals
    > are mentioned in the standard library.



    /*----------------8<------------------------------------->8------------------*/

    /* A simple code example to demonstrate the use of signal() function*/

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

    void sighandler(int signum);

    void sighandler(int signum)
    {
    static count=0;

    if (signum == SIGINT) /* Since the same handler(function)
    can be installed to handle more than one signal, the 2nd argument <int
    signum> provides a way to know which signal has invoked this handler
    at that time */
    {
    printf("Caught SIGINT signal...\n");
    count++;
    }

    else printf("This will never get printed here...\n");

    /* exit after catching the SIGINT 3 times */
    if (count == 3) exit(0);
    }

    main()
    {
    signal(SIGINT, sighandler); /* This function installs
    "sighandler" to handle the SIGINT and returns a pointer to the
    previously installed handler for this signal (which is the default
    handler SIG_DFL initially). If we try to install another handler to
    handle SIGINT at some other time... Then the new handler replaces this
    current one and returns a pointer to this handler. */

    /* Now pressing the terminals interrupt key (usually Ctrl+C) will
    generate the SIGINT signal. */

    for(;/* wait for the signal */;) {}
    }

    /*----------------8<------------------------------------->8------------------*/


    - Gana
    Ganesh, Jul 29, 2004
    #7
  8. Jackie

    goose Guest

    (Ganesh) wrote in message news:<>...
    > "Jackie" <> wrote in message news:<toLNc.1067$>...
    > > > Signals provide a way to handle asynchronous (and unexpected) events.
    > > > A signal (number) is associated with an event. Like:
    > > >
    > > > SIGFPE: associated with the event "Floating Point Error (FPE)". For
    > > > example: This occurs when the process tries to divide a number by zero
    > > > as in p=5/0.

    > >
    > > Thank you so much for replying. Can you give me a code example that shows
    > > how one may be able to use the signals in <signal.h> to handle asynchronous
    > > (and unexpected) events? Should I call this function: "int raise(int sig)"?
    > > I very much like to know how to use signals in a c code since the signals
    > > are mentioned in the standard library.

    >
    >
    > /*----------------8<------------------------------------->8------------------*/
    >
    > /* A simple code example to demonstrate the use of signal() function*/
    >
    > #include<stdio.h>
    > #include<signal.h>
    >
    > void sighandler(int signum);
    >
    > void sighandler(int signum)
    > {
    > static count=0;


    static sig_atomic_t count=0;
    >
    > if (signum == SIGINT) /* Since the same handler(function)
    > can be installed to handle more than one signal, the 2nd argument <int
    > signum> provides a way to know which signal has invoked this handler
    > at that time */
    > {
    > printf("Caught SIGINT signal...\n");


    dangerous calling printf ni a signal handler, no?

    > count++;
    > }
    >
    > else printf("This will never get printed here...\n");
    >
    > /* exit after catching the SIGINT 3 times */
    > if (count == 3) exit(0);
    > }
    >
    > main()


    int main (void)

    > {
    > signal(SIGINT, sighandler); /* This function installs
    > "sighandler" to handle the SIGINT and returns a pointer to the
    > previously installed handler for this signal (which is the default
    > handler SIG_DFL initially). If we try to install another handler to
    > handle SIGINT at some other time... Then the new handler replaces this
    > current one and returns a pointer to this handler. */
    >
    > /* Now pressing the terminals interrupt key (usually Ctrl+C) will
    > generate the SIGINT signal. */
    >
    > for(;/* wait for the signal */;) {}
    > }
    >


    dont you think it might be better for the loop in main to check the
    static variable and end when the condition is met? this will allow
    you to release all resources before exiting (not that there are
    any in this trivial program, but one never knows what maintenance
    programmer will come along and turn this into a non-trivial application).

    Its also neater to have an easily findable exit from main.

    goose,
    goose, Jul 29, 2004
    #8
  9. In article <>,
    goose <> wrote:
    > (Ganesh) wrote in message
    >news:<>...


    >/*----------------8<------------------------------------->8------------------*/
    >>
    >> /* A simple code example to demonstrate the use of signal() function*/
    >>
    >> #include<stdio.h>
    >> #include<signal.h>
    >>
    >> void sighandler(int signum);
    >>
    >> void sighandler(int signum)
    >> {
    >> static count=0;

    >
    > static sig_atomic_t count=0;


    Even this isn't enough for what he's doing; this makes it valid to store
    a value in count, but he's also accessing it to get the previous value
    with the increment.

    Quoth N869 (7.14.1.1):
    # [#5] If the signal occurs other than as the result of
    # calling the abort or raise function, the behavior is
    # undefined if the signal handler refers to any object with
    ^^^^^^^^^^^^^^^^^^^^^^^^^
    # static storage duration other than by assigning a value to
    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
    # an object declared as volatile sig_atomic_t, or the signal
    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
    # handler calls any function in the standard library other
    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
    # than the abort function or the signal function with the
    ^^^^
    # first argument equal to the signal number corresponding to
    # the signal that caused the invocation of the handler.
    # Furthermore, if such a call to the signal function results
    # in a SIG_ERR return, the value of errno is
    # indeterminate.198)


    >> if (signum == SIGINT) /* Since the same handler(function)
    >> can be installed to handle more than one signal, the 2nd argument <int
    >> signum> provides a way to know which signal has invoked this handler
    >> at that time */
    >> {
    >> printf("Caught SIGINT signal...\n");

    >
    >dangerous calling printf ni a signal handler, no?


    'Tis. See the second marked part of the quote from n869 above.


    >> count++;
    >> }
    >>
    >> else printf("This will never get printed here...\n");


    Unless somebody installs the handler for something other than SIGINT...

    >>
    >> /* exit after catching the SIGINT 3 times */
    >> if (count == 3) exit(0);


    What happens if the implementation resets the signal handler to SIG_DFL
    when the signal is raised? (Whether it does this is implementation-
    defined, see N869 7.14.1.1#3.)

    >> }
    >>
    >> main()

    >
    >int main (void)


    This is good form, but it's not the same importance as your other
    corrections. (`int main()' is the minimal form required by C99, but for
    C90 `main()' is treated by the compiler the same way as `int main(void)',
    the latter is merely generally accepted to be better style.)

    >> {
    >> signal(SIGINT, sighandler); /* This function installs
    >> "sighandler" to handle the SIGINT and returns a pointer to the
    >> previously installed handler for this signal (which is the default
    >> handler SIG_DFL initially). If we try to install another handler to
    >> handle SIGINT at some other time... Then the new handler replaces this
    >> current one and returns a pointer to this handler. */


    What happens if signal() fails here?


    >> /* Now pressing the terminals interrupt key (usually Ctrl+C) will
    >> generate the SIGINT signal. */
    >>
    >> for(;/* wait for the signal */;) {}
    >> }
    >>

    >
    >dont you think it might be better for the loop in main to check the
    >static variable and end when the condition is met? this will allow
    >you to release all resources before exiting (not that there are
    >any in this trivial program, but one never knows what maintenance
    >programmer will come along and turn this into a non-trivial application).
    >
    >Its also neater to have an easily findable exit from main.


    It also makes it possible to write the signal handler without invoking
    undefined behavior.
    Better would be to have a sig_atomic_t used as an "interrupt happened"
    flag at file scope that the signal handler simply sets:
    --------
    static volatile sig_atomic_t interrupted;
    void sighandler(int signum)
    {
    /*This calls abort() if we get a signal other than SIGINT; this
    is one of the few things that's guaranteed to be valid inside
    a signal handler (N869 7.14.1.1#4, #5)
    */
    assert(signum==SIGINT);
    interrupted=1;
    signal(signum,sighandler);
    }
    --------

    Then write the loop in main to check this flag and do "we've been
    interrupted" stuff when the flag is set:
    --------
    while(1)
    {
    static int count=0;

    /*Normally we'd want to be doing something useful inside this loop*/
    while(!interrupted)
    ;

    printf("Caught SIGINT signal...\n");
    if(++count>=3)
    break;

    interrupted=0;
    }
    --------


    dave

    --
    Dave Vandervies
    We also should expect to learn much of value from nonbelievers in the
    process. They too, it is rumored, are made in the image of God.
    --Daniel Taylor, _The Myth of Certainty_
    Dave Vandervies, Jul 29, 2004
    #9
  10. Jackie

    Villy Kruse Guest

    On Thu, 29 Jul 2004 16:54:43 +0000 (UTC),
    Dave Vandervies <> wrote:


    >
    > It also makes it possible to write the signal handler without invoking
    > undefined behavior.


    You still have behaviour which isn't well defined. If a new signal is
    reaised after sighandler has been entered but before it has called signal
    to reinstall the handler you don't know what would happen, unless the
    implementation defines what would happen. Also, the side effect on
    a pending input operation isn't specified. On some systems the io
    operation might terminate with an error, while one some other system it
    won't. If the io operation doesn't terminate then the program won't
    come around to test the "interrupted" variable until the io operation
    terminates for other reasons. In my opinion, signal is a minefield of
    undefined and implementation defined behaviour.


    > Better would be to have a sig_atomic_t used as an "interrupt happened"
    > flag at file scope that the signal handler simply sets:
    > --------
    > static volatile sig_atomic_t interrupted;
    > void sighandler(int signum)
    > {
    > /*This calls abort() if we get a signal other than SIGINT; this
    > is one of the few things that's guaranteed to be valid inside
    > a signal handler (N869 7.14.1.1#4, #5)
    > */
    > assert(signum==SIGINT);
    > interrupted=1;
    > signal(signum,sighandler);
    > }
    > --------
    >
    > Then write the loop in main to check this flag and do "we've been
    > interrupted" stuff when the flag is set:
    > --------
    > while(1)
    > {
    > static int count=0;
    >
    > /*Normally we'd want to be doing something useful inside this loop*/
    > while(!interrupted)
    > ;
    >
    > printf("Caught SIGINT signal...\n");
    > if(++count>=3)
    > break;
    >
    > interrupted=0;
    > }
    > --------
    >




    Villy
    Villy Kruse, Jul 30, 2004
    #10
  11. In article <>,
    Villy Kruse <nobody> wrote:
    >On Thu, 29 Jul 2004 16:54:43 +0000 (UTC),
    > Dave Vandervies <> wrote:
    >
    >> It also makes it possible to write the signal handler without invoking
    >> undefined behavior.

    >
    >You still have behaviour which isn't well defined. If a new signal is
    >reaised after sighandler has been entered but before it has called signal
    >to reinstall the handler you don't know what would happen, unless the
    >implementation defines what would happen.


    This is well-defined; there are two possibilities (either the signal
    will be suppressed until the handler exits or SIG_DFL will be installed
    in place of the user handler), and the implementation is required to
    document which one occurs. (There is one exception to this: SIGILL,
    for which the implementation is also allowed to "do nothing", but still
    required to document which choice is taken.) If it really matters,
    install SIG_IGN as the first action the handler takes, and you'll get
    the equivalent of "signal suppressed" whichever one the system does.


    > Also, the side effect on
    >a pending input operation isn't specified. On some systems the io
    >operation might terminate with an error, while one some other system it
    >won't. If the io operation doesn't terminate then the program won't
    >come around to test the "interrupted" variable until the io operation
    >terminates for other reasons.


    And if you're waiting for input for long enough for it to matter, you're
    probably running interactively anyways, so what use do you have for an
    interactive attention signal?


    > In my opinion, signal is a minefield of
    >undefined and implementation defined behaviour.


    Well, that's kind of the point; signal handlers are a reasonably well-
    defined hook into system-dependent behavior on asynchronous events.
    If you have things happening asynchronously, you need to be careful about
    what you do because you're likely to be in the middle of something, and
    you need to understand how the system handles asynchronous events if that
    handling will affect how you treat them; if everything is synchronous,
    you don't need to muck about with signals.


    dave

    --
    Dave Vandervies
    We also should expect to learn much of value from nonbelievers in the
    process. They too, it is rumored, are made in the image of God.
    --Daniel Taylor, _The Myth of Certainty_
    Dave Vandervies, Jul 30, 2004
    #11
  12. Jackie

    Villy Kruse Guest

    On Fri, 30 Jul 2004 17:11:27 +0000 (UTC),
    Dave Vandervies <> wrote:


    >>You still have behaviour which isn't well defined. If a new signal is
    >>reaised after sighandler has been entered but before it has called signal
    >>to reinstall the handler you don't know what would happen, unless the
    >>implementation defines what would happen.

    >
    > This is well-defined; there are two possibilities (either the signal
    > will be suppressed until the handler exits or SIG_DFL will be installed
    > in place of the user handler), and the implementation is required to
    > document which one occurs. (There is one exception to this: SIGILL,
    > for which the implementation is also allowed to "do nothing", but still
    > required to document which choice is taken.) If it really matters,
    > install SIG_IGN as the first action the handler takes, and you'll get
    > the equivalent of "signal suppressed" whichever one the system does.
    >


    Which means that unless you program for a specific system you won't
    know beforehand. For me that is anough to avoid signal() completely on
    POSIX sysytems in favour if sigaction() where you have more control over
    what behaviour you get. In this case neither the ANSI/ISO C standard
    nor the POSIX/SUS standard helps you to make usage of signal() portable.


    >
    >> Also, the side effect on
    >>a pending input operation isn't specified. On some systems the io
    >>operation might terminate with an error, while one some other system it
    >>won't. If the io operation doesn't terminate then the program won't
    >>come around to test the "interrupted" variable until the io operation
    >>terminates for other reasons.

    >
    > And if you're waiting for input for long enough for it to matter, you're
    > probably running interactively anyways, so what use do you have for an
    > interactive attention signal?
    >


    Think alarm signal in connection with network input.

    There are also programs which appearently don't react on kill signals
    for this reason because the program was written and test on a SystemV
    unix where signals will interrupt a read operation in progress, but
    now ported to BSD unix where this isn't the case. This isn't just a
    theoretical problem, but a very real problem when porting programs from
    on unix flavour to the other. And I couldn't say how it would behave
    when running on some non-unix system.

    Villy
    Villy Kruse, Aug 2, 2004
    #12
    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. Holger Joukl
    Replies:
    2
    Views:
    613
    Dieter Maurer
    Jun 7, 2004
  2. Michael Pronath
    Replies:
    1
    Views:
    1,143
    Diez B. Roggisch
    Jan 3, 2005
  3. Jack Orenstein

    threading.Thread vs. signal.signal

    Jack Orenstein, Sep 18, 2005, in forum: Python
    Replies:
    0
    Views:
    457
    Jack Orenstein
    Sep 18, 2005
  4. Grzegorz Kokosiñski
    Replies:
    1
    Views:
    312
    Chris
    May 26, 2008
  5. hhanff
    Replies:
    8
    Views:
    943
    hhanff
    Jul 23, 2010
Loading...

Share This Page