I understand that, from a signal handler function sigaction()
I should only call those functions that are "async-safe". But why is so?
相关问题
- How can I write a SIG{__DIE__} handler that does n
- What cause info can be readily collected in an iOS
- “kill -15” triggers the sigaction code but does no
- Python - prevent child threads from being affected
- SIGALRM while sleeping on Solaris 9
相关文章
- how to handle os.system sigkill signal inside pyth
- Is it possible to make an arbitrary program ignore
- Python core dump on sys.exit() from signal handler
- When is POSIX thread cancellation not immediate?
- When are GTK signals emitted
- Signal sent to both child and parent process
- IPC using Signals on linux
- Using long data inside signal handler.
Calling an unsafe function may lead to undefined behavior.
The Open Group Base Specifications Issue 7 (POSIX.1-2008), in its treatment of "Signal Concepts", says:
As to why unsafe functions are unsafe, there may be many reasons in a given implementation.
However, a previous version of the standard, Issue 6 (POSIX.1-2004), hints at one possible reason on some implementations. That version describes async-signal-safe functions as "either reentrant or non-interruptible by signals". So, consider a function which relies on static data to keep state but is interrupted by itself midway through its execution — can that data be trusted once control returns to the interrupted function?