Python守护线程读取标准输入时的不可预测行为及相关疑问

这个问题涉及到CPython解释器的关机流程、终端I/O的底层实现，以及不同版本/架构下的资源管理差异，我来逐一拆解你的四个疑问：

1. 为什么input()和sys.stdin.readline()行为不同？ #

根源在于这两个函数的底层实现逻辑差异：

• input()并不是简单封装sys.stdin.readline()，它会调用CPython内部的PyOS_Readline函数——这个函数不仅处理行读取，还会管理终端的TTY状态、处理信号（比如SIGINT），并且深度依赖Python的全局I/O缓冲锁。当主线程退出、解释器开始进入关机（finalize）阶段时，input()所在的守护线程还在阻塞等待终端输入，并且持有/尝试获取stdin的缓冲锁，和关机流程的资源回收产生冲突。
• 而sys.stdin.readline()直接操作底层的文件对象读取，逻辑更轻量化，不涉及PyOS_Readline的额外终端交互逻辑。当解释器开始关机时，文件对象的资源会被快速回收，读取操作会被系统主动中断，所以守护线程会直接退出，进程正常结束。

简单说：input()和解释器的终端交互、锁机制绑定得更深，关机时的资源冲突没法被妥善处理；readline()更“底层”，能配合解释器的关机流程正常退出。

2. 为什么不同Python版本行为不同？ #

CPython在不同版本中对关机阶段的守护线程和资源回收逻辑做了明确调整：

• Python 2.7：关机流程的资源检查非常宽松，不会主动中断守护线程的I/O操作，不管是raw_input还是readline()，都会一直阻塞在终端读取上，不会触发崩溃。
• Python 3.10+：官方优化了关机阶段的资源管理，新增了对I/O锁竞争的检测。当守护线程在关机时还持有关键I/O锁，解释器会尝试终止操作，但input()的终端阻塞无法被安全中断——所以要么一直挂着（交互式终端下），要么触发致命错误（非交互式场景）。3.13相比3.10又进一步收紧了锁的检测逻辑，崩溃提示更明确。

3. 为什么不同机器（x86 vs ARM）行为不同？ #

这和操作系统的终端子系统、线程调度以及底层库的实现差异直接相关：

• x86 Arch Linux：终端驱动在主线程退出后，不会主动中断守护线程的终端读取系统调用（read()），所以input()会一直阻塞等待输入，直到你手动终止进程。
• ARM Ubuntu：其终端子系统或glibc库的实现会检测到进程的主控制线程已退出，主动中断守护线程的阻塞I/O操作，所以input()和readline()都会正常退出。

另外，不同架构下的锁获取、线程上下文切换逻辑有细微差别，也会影响解释器关机时的资源冲突处理结果。

4. 为什么重定向stdout会触发崩溃？ #

当你把stdout重定向到/dev/null时，stdin会从交互式TTY变成非交互式设备（终端的“会话组”被打破了）：

• 此时input()的底层逻辑会切换到非交互式读取模式，不再依赖终端的TTY状态，但它仍然持有stdin的缓冲锁。
• 当解释器进入关机阶段，开始回收I/O资源时，会尝试获取这个锁来销毁sys.stdin的缓冲对象，但守护线程还在操作这个锁，导致死锁。CPython检测到这种在关机阶段无法解决的锁竞争，就会抛出致命错误并触发core dump，也就是你看到的IOT instruction (core dumped)和错误日志。

额外验证小技巧 #

你可以用strace python3 test.py跟踪系统调用，会发现交互式场景下input()一直阻塞在read(0, ...)（终端读取）；而sys.stdin.readline()在主线程退出后，read()会被返回EINTR（中断），线程随即退出。

备注：内容来源于stack exchange，提问作者pjones123