Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C Programming > Please explain signal handler behaviour

Reply
Thread Tools

Please explain signal handler behaviour

 
 
manochavishal@gmail.com
Guest
Posts: n/a
 
      03-15-2006
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

 
Reply With Quote
 
 
 
 
Rod Pemberton
Guest
Posts: n/a
 
      03-15-2006

<(E-Mail Removed)> wrote in message
news:(E-Mail Removed) ups.com...
> 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.15"

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




 
Reply With Quote
 
 
 
 
Walter Roberson
Guest
Posts: n/a
 
      03-15-2006
In article <(E-Mail Removed). com>,
http://www.velocityreviews.com/forums/(E-Mail Removed) <(E-Mail Removed)> 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
 
Reply With Quote
 
Jack Klein
Guest
Posts: n/a
 
      03-16-2006
On Wed, 15 Mar 2006 10:21:23 -0500, "Rod Pemberton"
<(E-Mail Removed)> wrote in comp.lang.c:

>
> <(E-Mail Removed)> wrote in message
> news:(E-Mail Removed) ups.com...
> > 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.15"
>
> "15 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/~a...FAQ-acllc.html
 
Reply With Quote
 
Dave Thompson
Guest
Posts: n/a
 
      03-27-2006
On Wed, 15 Mar 2006 15:31:58 +0000 (UTC), http://www.velocityreviews.com/forums/(E-Mail Removed)-cnrc.gc.ca
(Walter Roberson) wrote:

> In article <(E-Mail Removed). com>,
> (E-Mail Removed) <(E-Mail Removed)> 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
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Re: Please explain this strange Python behaviour Tim Chase Python 3 04-30-2009 03:40 PM
Please explain this strange Python behaviour Train Bwister Python 1 04-30-2009 11:33 AM
Please Explain This behaviour..., Pranav C Programming 14 09-08-2008 05:59 PM
Could some1 please explain this String behaviour priyom Java 5 11-25-2006 08:59 AM
Please explain these regexps: funny lookahead behaviour Jeremy Henty Ruby 7 06-05-2006 12:43 AM



Advertisments