Python文档POSIX环境下锁获取可被信号中断的含义解析

官方变更原文中文翻译：

3.2版本变更：若底层线程实现支持，POSIX平台上的锁获取操作现已支持被信号中断。

对两种理解的逐一验证说明 #

关于第一种理解 #

这个理解只对了一半，并非该特性的设计初衷：

• 3.2版本调整这个逻辑，核心是解决此前锁等待完全卡死信号响应的问题。3.2之前POSIX平台上Python调用的是不可中断的pthread_mutex_lock接口拿锁，只要线程堵在等锁步骤，哪怕进程收到SIGINT（Ctrl+C触发的中断信号）、SIGTERM这类信号，对应的信号处理函数必须等锁拿到之后才能执行，相当于卡锁的时候按Ctrl+C根本停不掉程序。
• 3.2之后换成了可中断的锁等待逻辑，只要底层pthread库支持，等锁过程中收到信号，会立刻跳出锁等待先执行信号处理函数，不会硬卡到锁拿到为止。
• 你提到的「外部发信号终止特定线程的锁等待」在技术上确实能实现，但Python本身没提供任何接口让你定位「哪个线程当前正在执行锁获取操作」。真要做的话只能靠gdb这类系统调试工具附加到Python进程，翻每个线程的调用栈确认是不是卡在锁获取的系统调用上，再给对应线程发信号。但要注意：直接给Python子线程发原生信号非常容易把解释器搞崩，官方从来没推荐过这种用法，普通开发场景完全没必要这么操作。

关于第二种理解 #

这个理解完全正确：

• 带timeout参数的阻塞拿锁逻辑，在支持该特性的POSIX平台上，就是靠SIGALRM信号触发中断来实现超时退出的，完全依赖这次新增的可中断锁能力。
• 不支持这个特性的系统主要有两类：
  • 所有非POSIX系统，最典型的就是Windows平台：Windows原生线程锁不支持信号中断，Python在Windows上的锁超时是靠独立的等待+轮询逻辑实现的，完全不走信号机制
  • 底层pthread库不支持可中断互斥锁的老旧POSIX系统，比如2.6内核之前的老Linux发行版、部分版本过旧的商用UNIX系统
• 在不支持该特性的系统上，timeout参数不会完全失效，但是会有两个明显问题：一是超时精度很差，比如你设了3秒超时，实际可能等4、5秒才会返回；二是等锁期间信号没法及时响应，卡锁的时候按Ctrl+C还是会等很久才有反应。

内容的提问来源于stack exchange，提问作者Vespene Gas