python - 在 Windows 上，python 启动器 'py' 做什么让 control-C 在进程组之间交叉？

Question

对，这非常晦涩...

因此在 Windows 上，当您按下 control-C 来中断控制台程序时，这会向进程发送一个 CTRL_C_EVENT。您也可以通过 GenerateConsoleCtrlEvent 手动执行此操作.在 Python 中，os.kill 充当 C 级 GenerateConsoleCtrlEvent 的包装器，并允许我们通过以下方式向当前进程发送 CTRL_C_EVENT做:

os.kill(os.getpid(), signal.CTRL_C_EVENT)

但是，这不仅适用于当前流程——它实际上适用于该流程所属的整个“流程组”。

我有一个测试套件，它调用 os.kill 就像您在上面看到的那样，作为一些测试的一部分，以确保我的程序的 control-C 处理正常工作。但是，当在 appveyor 上运行这个测试套件时，这会导致问题，因为显然 appveyor 的一些基础设施在同一个“进度组”中并且被破坏了。

解决方案是我们需要生成带有 CREATE_NEW_PROCESS_GROUP 标志集的测试套件，这样它的 CTRL_C_EVENT 就不会“泄漏”给父级。这很容易做到。但是...

如果我使用 CREATE_NEW_PROCESS_GROUP 并使用 python whatever.py 运行子脚本，那么它会按预期工作:CTRL_C_EVENT 仅限于 child 。

如果我使用 CREATE_NEW_PROCESS_GROUP 并使用 py whatever.py 运行子脚本(即使用 python launcher ，这应该等同于运行 python 直接)，那么 CREATE_NEW_PROCESS_GROUP 似乎没有任何效果:CTRL_C_EVENT 也会影响父级!

这是一个最小的示例程序，它仅对自身使用 os.kill 然后检查它是否有效(小问题:CREATE_NEW_PROCESS_GROUP 设置 CTRL_C_EVENT在子进程中被忽略，所以这里有一些绒毛使用 SetConsoleCtrlHandler 取消忽略它): https://github.com/njsmith/appveyor-ctrl-c-test/blob/master/a.py

这是我用来运行上述程序的包装器脚本: https://github.com/njsmith/appveyor-ctrl-c-test/blob/master/run-a.py

如果包装器脚本运行 python a.py，那么一切正常。如果包装器脚本运行 py a.py，则包装器脚本会收到一个 KeyboardInterrupt。

所以我的问题是:这到底是怎么回事？ py 启动器与 python 有何不同导致 CTRL_C_EVENT“泄漏”到父进程中，即使它在不同的进程中团体？这怎么可能？

(我最初发现这个是因为运行 pytest a.py 就像 py a.py 一样，即被破坏了，但是 python -m pytest a.py 有效，大概是因为 pytest 入口点 uses the py launcher .)

Answer 1

每个进程都在一个进程组中。它要么继承其父组，要么通过 CREATE_NEW_PROCESS_GROUP 创建标志创建为新组的组长。据我所知，GenerateConsoleCtrlEvent 是唯一使用进程组的 API，并且没有查询进程组 ID 的 API。您可以从 PEB 中的 ProcessParameters 获取它，但这涉及使用未记录的内部结构。没有人应该这样做，因此 GenerateConsoleCtrlEvent 应该只发送到组 0 以广播事件或发送到您知道作为新组创建的子进程。

您在这里发现的问题是，将事件发送到附加到控制台但不是组长的进程会被静默处理，就好像目标是组 0 一样。特别是在您的情况下，您开始py.exe 作为组长，然后尝试将 CTRL_C_EVENT 发送到 python.exe，即 os.getpid()。在这种情况下，您必须发送到 os.getppid()。

由于 os.kill 的困惑实现，此问题在 Windows 上的 Python 脚本中很常见。它将进程 ID 和进程组 ID 合并。如果 GenerateConsoleCtrlEvent 用于 os.killpg(当前未在 Windows 上实现)并且 TerminateProcess 单独用于 os.kill。

调用 os.kill(os.getpid(), signal.CTRL_C_EVENT); time.sleep(10) 时遇到随机挂起可能是由于竞争条件. time.sleep 由Modules/timemodule.c 中的pysleep 实现。在 Windows 上，当在主线程中调用时，它等待由 SIGINT 的信号处理程序设置的事件(但由于某些原因不是 SIGBREAK)。此处可能的竞争是 pysleep 在等待事件之前重置事件。信号处理程序在新线程上执行，有时它可能在 pysleep 重置事件之前已经设置了事件。这是可以想象的，因为执行 CPython 字节码相对较慢。也就是说，我预计这将是一场势均力敌的比赛，因为创建控制处理程序线程涉及很多步骤，如下面的 Windows 10 概述所示。

1. Console Client -- Main Thread (python.exe)
   kernelbase!GenerateConsoleCtrlEvent
   kernelbase!ConsoleCallServer
   ntdll!NtDeviceIoControlFile

2. Device Driver (condrv.sys)
   condrv!CdpDispatchDeviceControl

    3a. Console Server (conhost.exe)
        ntdll!NtDeviceIoControlFile
        conhostv2!SrvGenerateConsoleCtrlEvent
        conhostv2!ProcessCtrlEvents
        user32!ConsoleControl
        ntdll!CsrClientCallServer
        ntdll!NtRequestWaitReplyPort (ALPC)

    3b. Windows Server (csrss.exe)
        ntdll!NtAlpcSendWaitReceivePort
        winsrv!SrvEndTask
        winsrv!CreateCtrlThread
        ntdll!NtCreateThreadEx (Control Thread)

    3c. Console Client -- Control Thread (python.exe)
        kernelbase!CtrlRoutine
        ucrtbase!ctrlevent_capture (Emulate SIGINT)
        python36!signal_handler
        kernelbase!SetEvent (SIGINT Event -- Race with step 4)

4. Console Client -- Main Thread (python.exe)
   python36!pysleep
   kernelbase!ResetEvent (SIGINT Event -- Race with step 3c)
   kernelbase!WaitForSingleObjectEx (SIGINT Event)
   python36!PyErr_CheckSignals       
   python36!signal_default_int_handler

如果竞争条件是问题所在，那么在 GenerateConsoleCtrlEvent 被调用之前给 time.sleep 足够的时间来重置事件应该可以解决它。尝试使用 threading.Timer 稍稍延迟调用 os.kill。