GSoC 2026：改进 lit
内容提要
2026年GSoC项目优化LLVM测试工具lit：清理Python 2遗留代码，将执行引擎迁移至ProcessPoolExecutor，修复CPython并发缺陷及高核数性能回退；让cat和diff进程内运行，提速约6.9%；修复env管道短路bug。实验表明线程池因GIL争用不可行，asyncio仅在低并发下更快。
延伸解读
从 multiprocessing 到 ProcessPoolExecutor
文章详细记录了将 lit 的执行引擎从 multiprocessing.Pool 迁移到 ProcessPoolExecutor 的过程。迁移修复了超时计算和结果匹配两个 bug，但触发了 CPython 的两个并发缺陷：macOS 上 shutdown 顺序导致的死锁，以及高核数下唤醒管道写满导致的阻塞。最终通过窗口化提交和回调收集解决。这提醒我们，标准库的并发原语在不同平台和规模下可能有未暴露的边界问题，迁移前需充分测试。
线程池为何在 lit 中不可行
作者尝试用 ThreadPoolExecutor 替代进程池，结果在 10 核和 16 核机器上分别慢 1.86 倍和 5.42 倍。Scalene 分析显示，由于 lit 大量时间花在子进程的创建和等待上，线程频繁争用 GIL，导致原生和 C 扩展时间占比从 10% 左右升至 34% 以上。这说明对于系统调用密集型的任务，线程池不仅无法利用多核，反而会因 GIL 成为瓶颈。在自由线程 Python 普及前，进程池仍是更优选择。
asyncio 引擎的适用边界
作者实现了一个单进程 asyncio 执行引擎，在 -j1 时比进程池快 1.8 到 2.3 倍，因为消除了 IPC 和 pickle 开销；但在 -j4 及以上时反而慢 1.5 到 1.9 倍，因为单个事件循环无法并行利用多核。交叉点在 -j2 到 -j3 之间。这表明 asyncio 适合低并发或 IO 密集型场景，而 lit 的测试执行需要多核并行，因此 asyncio 引擎未被采纳。读者可据此判断自己的工具链是否适合异步方案。
cat 和 diff 进程内化的收益与实现
将 cat 和 diff 从外部进程改为进程内执行，在六个内置命令密集的测试套件中，中位运行时间从 67.66 秒降至 63.02 秒，提升约 6.9%，且内存无增长、输出完全一致。实现上通过重构 main() 为可注入 IO 流的 run() 函数，并引入 InProcessPipe 模拟 subprocess.Popen 接口，使管道执行器无需区分进程内外。这种鸭子类型抽象既保持了兼容性，又消除了 Python 解释器启动开销，是低风险优化的典型案例。
Q&A
GSoC 2026 中改进 lit 的项目目标是什么？
该项目旨在优化 LLVM 测试工具 lit，具体包括：清理 Python 2 遗留代码，将执行引擎迁移到 ProcessPoolExecutor，修复 CPython 并发缺陷及高核数性能回退，让 cat 和 diff 进程内运行以提速约 6.9%，并修复 env 管道短路 bug。
为什么 lit 的线程池执行引擎不可行？
因为 lit 大部分时间在生成和等待子进程，工作线程会持续争用 Python 的全局解释器锁（GIL）。基准测试显示，线程池比进程池慢 1.86 倍到 5.42 倍，Scalene 分析表明原生和 C 扩展时间占比大幅上升，集中在 subprocess.py、threading.py 和 posixpath.py 中。
lit 迁移到 ProcessPoolExecutor 时遇到了哪些 CPython 并发缺陷？
遇到了两个缺陷：一是 macOS 上 ProcessPoolExecutor.shutdown(wait=True) 调用 join_thread() 在 join 工作进程之前，导致 feeder 线程无法排空而阻塞；二是 lit 一次性提交所有测试 future，每个提交向唤醒管道写入 4 字节，管道缓冲区 64 KiB 只能容纳 16384 次写入，超过后 submit() 会阻塞并持有 _shutdown_lock。
如何解决高核数机器上 lit 的性能回退？
回退原因是 concurrent.futures.wait() 每次迭代重新注册监听器回调，导致 O(N) 扫描成本随并发增长。解决方案是用 SimpleQueue 和 add_done_callback() 替代 wait()，每个 future 在提交时注册一次回调。这使 64 核上的 56% 回退降至约 8%，后续 Paul Kirth 添加了工作端任务批处理，最终 check-llvm 从 105.2s 降至 48.38s，比迁移前基线快 4.6%。
lit 中 cat 和 diff 进程内运行带来了什么好处？
将 cat 和 diff 改为进程内运行后，在六个内置命令密集的测试套件中，中位墙钟时间从 67.66s 降至 63.02s，提速约 6.9%，且 RSS 无增加，测试输出字节级一致。实现上通过重构 main() 委托给 run() 函数，并引入 InProcessPipe 垫片以兼容管道。
lit 的 env 管道短路 bug 是什么？如何修复？
该 bug 是裸 env 命令没有子命令时从管道执行器提前返回，静默丢弃后续命令，导致如 env | FileCheck 跳过验证。修复方法是利用为 cat/diff 构建的 InProcessPipe 抽象，将裸 env 通过该管道运行，而不是按原计划分离 env 处理。修复后 FileCheck 开始运行，并暴露出三个之前被掩盖的测试 bug。
lit 的 asyncio 单进程执行引擎在什么情况下更快？
asyncio 引擎在低并发下更快：在 -j1 时比进程池快 1.8 到 2.3 倍，因为消除了 IPC、pickling 和进程池开销；但在 -j4 及以上时慢 1.5 到 1.9 倍，因为单个 Python 事件循环无法跨多个 CPU 核心并行运行任务。交叉点在 -j2 和 -j3 之间。
lit 项目中有哪些未来工作计划？
未来工作包括：添加类型注解；在随机顺序下测试 ProcessPoolExecutor；解决全测试套件规模下的执行器和 IPC 开销（问题 #218095）；以及一些已识别的优化，如用 functools.lru_cache 替换自定义正则缓存、用 os.scandir() 替代 os.listdir() 加 isdir()、预编译 kPdbgRegex 等。
