Please explain signal handler behaviour

Discussion in 'C Programming' started by manochavishal@gmail.com, Mar 15, 2006.

  1. Guest

    Why would a signal handler cannot in general call standard library
    functions.

    I have read whats is said in Standard but needs an explaination on that
    as i couldn't uunderstand it.

    Thanx in advance
    , Mar 15, 2006
    #1
    1. Advertising

  2. <> wrote in message
    news:...
    > Why would a signal handler cannot in general call standard library
    > functions.
    >
    > I have read whats is said in Standard but needs an explaination on that
    > as i couldn't uunderstand it.
    >


    From 7.1.2
    "4 The functions in the standard library are not guaranteed to be reentrant
    and may modify
    objects with static storage duration.158)"

    "158) Thus, a signal handler cannot, in general, call standard library
    functions."

    This has to do with the design of the OS. Many OS's only use non-reentrant
    functions. That is, the function can't be called again until it completes
    it's first call. Since most OS's use non-reentrant functions, the signal
    handler would cause some form of undefined behavior: lockup, crash,
    segmentation fault, if the signal handler called the same function that was
    interrupted. For example, if the signal handler is called and interrupts a
    call to printf() and then the signal handler calls printf(), undefined
    behavior occurs. This means that most signal handlers are implemented
    without using the standard library.


    Rod Pemberton
    Rod Pemberton, Mar 15, 2006
    #2
    1. Advertising

  3. In article <>,
    <> wrote:
    >Why would a signal handler cannot in general call standard library
    >functions.


    >I have read whats is said in Standard but needs an explaination on that
    >as i couldn't uunderstand it.


    A signal handler can interrupt existing operations (including
    library calls) between sequence points, possibly even
    terminating an time-consuming instruction (such as division)
    {requiring that the instruction be restarted when the handler
    completes.}

    Library calls are allowed to have internal persistant state
    that might get overwritten if the same library call were invoked
    in the signal handler. Or possibly even a different library call,
    as there are tight ties between some of them.

    I/O is the obvious example: if a library routine is just about
    to update the buffer pointer when an I/O routine gets invoked
    in the signal handler, then the result could be program crashes
    that were quite difficult to track down.

    Rather than put restrictions on the ways that each library function
    may use persistant state, the C standard says "Only these very few
    things are certain to be safe."

    There are other standards, such as POSIX.1, that go into much more
    detail about exactly which routines are safe in signal handlers
    and which ones are not. POSIX.1 does not invalidate this section
    of the C standard, as C allows implementations to offer additional
    functionality... but if you used a POSIX.1 guarantee of safety then
    as soon as you took your C program to a non-POSIX.1 system, all
    bets would be off again.

    --
    Okay, buzzwords only. Two syllables, tops. -- Laurie Anderson
    Walter Roberson, Mar 15, 2006
    #3
  4. Jack Klein Guest

    On Wed, 15 Mar 2006 10:21:23 -0500, "Rod Pemberton"
    <> wrote in comp.lang.c:

    >
    > <> wrote in message
    > news:...
    > > Why would a signal handler cannot in general call standard library
    > > functions.
    > >
    > > I have read whats is said in Standard but needs an explaination on that
    > > as i couldn't uunderstand it.
    > >

    >
    > From 7.1.2
    > "4 The functions in the standard library are not guaranteed to be reentrant
    > and may modify
    > objects with static storage duration.158)"
    >
    > "158) Thus, a signal handler cannot, in general, call standard library
    > functions."
    >
    > This has to do with the design of the OS. Many OS's only use non-reentrant
    > functions.


    This doesn't necessarily have anything at all to do with the OS.

    Admittedly, it would be difficult, but not impossible, to make C
    library functions reentrant on a platform where the underlying OS was
    not. But it is quite possible to make C library functions
    non-reentrant even if the underlying OS is reentrant.

    The point is that the C standard does not require standard library
    functions to be reentrant regardless of whether or not a host OS makes
    it easy, difficult, or flat out impossible.

    --
    Jack Klein
    Home: http://JK-Technology.Com
    FAQs for
    comp.lang.c http://c-faq.com/
    comp.lang.c++ http://www.parashift.com/c -faq-lite/
    alt.comp.lang.learn.c-c++
    http://www.contrib.andrew.cmu.edu/~ajo/docs/FAQ-acllc.html
    Jack Klein, Mar 16, 2006
    #4
  5. On Wed, 15 Mar 2006 15:31:58 +0000 (UTC), -cnrc.gc.ca
    (Walter Roberson) wrote:

    > In article <>,
    > <> wrote:
    > >Why would a signal handler cannot in general call standard library
    > >functions.

    >
    > >I have read whats is said in Standard but needs an explaination on that
    > >as i couldn't uunderstand it.

    >
    > A signal handler can interrupt existing operations (including
    > library calls) between sequence points, possibly even
    > terminating an time-consuming instruction (such as division)
    > {requiring that the instruction be restarted when the handler
    > completes.}
    >

    Library functions aren't required to contain sequence points except at
    entry and exit, and even if they do, it doesn't matter whether an
    interrupt occurs at one or not. What matters is whether the interrupt
    occurs while the library is "in the middle" of doing something.

    > Library calls are allowed to have internal persistant state
    > that might get overwritten if the same library call were invoked
    > in the signal handler. Or possibly even a different library call,
    > as there are tight ties between some of them.
    >

    Right.

    > I/O is the obvious example: if a library routine is just about
    > to update the buffer pointer when an I/O routine gets invoked
    > in the signal handler, then the result could be program crashes
    > that were quite difficult to track down.
    >

    In that particular case garbled output is rather more likely, but in
    general almost any kind of problem up to crashing is possible.

    > Rather than put restrictions on the ways that each library function
    > may use persistant state, the C standard says "Only these very few
    > things are certain to be safe."
    >

    Right.

    > There are other standards, such as POSIX.1, that go into much more
    > detail about exactly which routines are safe in signal handlers
    > and which ones are not. POSIX.1 does not invalidate this section
    > of the C standard, as C allows implementations to offer additional
    > functionality... but if you used a POSIX.1 guarantee of safety then
    > as soon as you took your C program to a non-POSIX.1 system, all
    > bets would be off again.


    And the async-safe functions in POSIX are, not by accident, exactly
    those that traditionally were implemented in the Unix kernel, and thus
    pseudo-uninterruptible or at least only "gracefully" interruptible.

    - David.Thompson1 at worldnet.att.net
    Dave Thompson, Mar 27, 2006
    #5
    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. priyom
    Replies:
    5
    Views:
    419
    priyom
    Nov 25, 2006
  2. Pranav

    Please Explain This behaviour...,

    Pranav, Sep 5, 2008, in forum: C Programming
    Replies:
    14
    Views:
    469
    Default User
    Sep 8, 2008
  3. Train Bwister
    Replies:
    1
    Views:
    276
    Diez B. Roggisch
    Apr 30, 2009
  4. Tim Chase
    Replies:
    3
    Views:
    295
    John Posner
    Apr 30, 2009
  5. Jeremy Henty
    Replies:
    7
    Views:
    111
    Jeremy Henty
    Jun 5, 2006
Loading...

Share This Page