`signal` — 为异步事件设置处理程序 ¶

此模块提供在 Python 中使用信号处理程序的机制。

一般规则 ¶

The signal.signal() 函数允许定义要执行的自定义处理程序，当收到信号时。有安装少量默认处理程序： SIGPIPE 被忽略 (因此，可以将在管道和套接字中写入错误报告成普通 Python 异常) 和 SIGINT 被翻译成 KeyboardInterrupt 异常若父级进程没有改变它。

特定信号处理程序一旦设置，仍会安装直到被明确重置 (Python 模拟 BSD 风格接口，不管底层实现)，除了异常处理程序 SIGCHLD 遵循底层实现。

On WebAssembly platforms, signals are emulated and therefore behave differently. Several functions and signals are not available on these platforms.

Python 信号处理程序的执行 ¶

Python 信号处理程序在低级 C 信号处理程序内，不会获得执行。相反，低级信号处理程序设置标志告诉虚拟机稍后要执行相应 Python 信号处理程序 (例如下一 bytecode 指令)。这有后果：

它使捕获同步错误变得意义不大像 SIGFPE or SIGSEGV 是由 C 代码中的无效操作造成的。Python 将从信号处理程序返回到 C 代码，很可能再次引发相同信号，导致 Python 被明显挂起。从 Python 3.3 起，可以使用 faulthandler 模块报告同步错误。
以纯 C 实现的长时间运行的计算 (例如：正则表达式匹配大量文本) 可以在任意时间内不间断运行，不管收到什么信号。将调用 Python 信号处理程序当计算完成时。
若处理程序引发异常，它会在主线程中被 "无中生有" 引发。见下文注意事项了解讨论。

信号和线程 ¶

Python 信号处理程序始终在主解释器的主 Python 线程中执行，即使信号是在另一线程中收到的。这意味着不可以把信号，用作线程间的通信手段。可以使用同步原语来自 threading 模块代替。

此外，只允许主解释器的主线程设置新的信号处理程序。

模块内容 ¶

3.5 版改变：信号 (SIG*)，处理程序 ( SIG_DFL , SIG_IGN ) and sigmask ( SIG_BLOCK , SIG_UNBLOCK , SIG_SETMASK ) 下面列出的相关常数被转换成 enums ( Signals , Handlers and Sigmasks 分别)。 getsignal() , pthread_sigmask() , sigpending() and sigwait() 函数返回人类可读的 enums as Signals 对象。

signal 模块定义了 3 个枚举：

class 信号。信号 ¶

enum.IntEnum collection of SIG* constants and the CTRL_* constants.

Added in version 3.5.

范例 ¶

Here is a minimal example program. It uses the


alarm()

function to limit the time spent waiting to open a file; this is useful if the file is for a serial device that may not be turned on, which would normally cause the


os.open()

to hang indefinitely. The solution is to set a 5-second alarm before opening the file; if the operation takes too long, the alarm signal will be sent, and the handler raises an exception.

import signal, os def handler(signum, frame): signame = signal.Signals(signum).name print(f'Signal handler called with signal {signame} ({signum})') raise OSError("Couldn't open device!") # Set the signal handler and a 5-second alarm signal.signal(signal.SIGALRM, handler) signal.alarm(5) # This open() may hang indefinitely fd = os.open('/dev/ttyS0', os.O_RDWR) signal.alarm(0) # Disable the alarm

有关 SIGPIPE 的注意事项 ¶

Piping output of your program to tools like head(1) will cause a


SIGPIPE

signal to be sent to your process when the receiver of its standard output closes early. This results in an exception like


BrokenPipeError: [Errno 32] Broken pipe

. To handle this case, wrap your entry point to catch this exception as follows:

import os import sys def main(): try: # simulate large output (your code replaces this loop) for x in range(10000): print("y") # flush output here to force SIGPIPE to be triggered # while inside this try block. sys.stdout.flush() except BrokenPipeError: # Python flushes standard streams on exit; redirect remaining output # to devnull to avoid another BrokenPipeError at shutdown devnull = os.open(os.devnull, os.O_WRONLY) os.dup2(devnull, sys.stdout.fileno()) sys.exit(1) # Python exits with error code 1 on EPIPE if __name__ == '__main__': main()

Do not set


SIGPIPE

’s disposition to


SIG_DFL

in order to avoid


BrokenPipeError

. Doing that would cause your program to exit unexpectedly whenever any socket connection is interrupted while your program is still writing to it.

有关信号处理程序和异常的注意事项 ¶

If a signal handler raises an exception, the exception will be propagated to the main thread and may be raised after any bytecode instruction. Most notably, a


KeyboardInterrupt

may appear at any point during execution. Most Python code, including the standard library, cannot be made robust against this, and so a


KeyboardInterrupt

(or any other exception resulting from a signal handler) may on rare occasions put the program in an unexpected state.

To illustrate this issue, consider the following code:

class SpamContext: def __init__(self): self.lock = threading.Lock() def __enter__(self): # If KeyboardInterrupt occurs here, everything is fine self.lock.acquire() # If KeyboardInterrupt occurs here, __exit__ will not be called ... # KeyboardInterrupt could occur just before the function returns def __exit__(self, exc_type, exc_val, exc_tb): ... self.lock.release()

For many programs, especially those that merely want to exit on


KeyboardInterrupt

, this is not a problem, but applications that are complex or require high reliability should avoid raising exceptions from signal handlers. They should also avoid catching


KeyboardInterrupt

as a means of gracefully shutting down. Instead, they should install their own


SIGINT

handler. Below is an example of an HTTP server that avoids


KeyboardInterrupt

import signal import socket from selectors import DefaultSelector, EVENT_READ from http.server import HTTPServer, SimpleHTTPRequestHandler interrupt_read, interrupt_write = socket.socketpair() def handler(signum, frame): print('Signal handler called with signal', signum) interrupt_write.send(b'\0') signal.signal(signal.SIGINT, handler) def serve_forever(httpd): sel = DefaultSelector() sel.register(interrupt_read, EVENT_READ) sel.register(httpd, EVENT_READ) while True: for key, _ in sel.select(): if key.fileobj == interrupt_read: interrupt_read.recv(1) return if key.fileobj == httpd: httpd.handle_request() print("Serving on port 8000") httpd = HTTPServer(('', 8000), SimpleHTTPRequestHandler) serve_forever(httpd) print("Shutdown...")

`signal` — 为异步事件设置处理程序 ¶

一般规则 ¶

Python 信号处理程序的执行 ¶

信号和线程 ¶

模块内容 ¶

范例 ¶

有关 SIGPIPE 的注意事项 ¶

有关信号处理程序和异常的注意事项 ¶

内容表

上一话题

下一话题

本页

内容表

上一话题

下一话题

本页

signal — 为异步事件设置处理程序 ¶

一般规则 ¶

Python 信号处理程序的执行 ¶

信号和线程 ¶

模块内容 ¶

范例 ¶

有关 SIGPIPE 的注意事项 ¶

有关信号处理程序和异常的注意事项 ¶

内容表

上一话题

下一话题

本页

`signal` — 为异步事件设置处理程序 ¶