Please explain signal handler behaviour

[manochavishal]

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

 

[Rod Pemberton]

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

 

[Walter Roberson]

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.

 

[Jack Klein]

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.

 

[Dave Thompson]

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