在Windows中使用子进程Popen.send_signal(CTRL_C_EVENT)时如何达到预期的结果?
在 Windows 中的 python 2.7 中,根据文档,您可以发送 CTRL_C_EVENT (Python 2.7 子进程 Popen.send_signal 文档)。 但是,当我尝试时,我没有在子进程中收到预期的键盘中断。
这是父进程的示例代码:
# FILE : parentProcess.py
import subprocess
import time
import signal
CREATE_NEW_PROCESS_GROUP = 512
process = subprocess.Popen(['python', '-u', 'childProcess.py'],
stdin=subprocess.PIPE,
stdout=subprocess.PIPE,
stderr=subprocess.STDOUT,
universal_newlines=True,
creationflags=CREATE_NEW_PROCESS_GROUP)
print "pid = ", process.pid
index = 0
maxLoops = 15
while index < maxLoops:
index += 1
# Send one message every 0.5 seconds
time.sleep(0.5)
# Send data to the subprocess
process.stdin.write('Bar\n')
# Read data from the subprocess
temp = process.stdout.readline()
print temp,
if (index == 10):
# Send Keyboard Interrupt
process.send_signal(signal.CTRL_C_EVENT)
这是子进程的示例代码:
# FILE : childProcess.py
import sys
while True:
try:
# Get data from main process
temp = sys.stdin.readline()
# Write data out
print 'Foo ' + temp,
except KeyboardInterrupt:
print "KeyboardInterrupt"
如果我运行文件parentProcess.py,我预计会得到“Foo Bar”十次,然后是“KeyboardInterrupt”,后跟“Foo Bar” 4 次,但我得到了 15 次“Foo Bar”。
有没有办法让 CTRL_C_EVENT 充当键盘中断,就像 SIGINT 在 Linux 中的行为一样?
经过一些阅读后,我发现一些信息似乎与有关 CTRL_C_EVENT 的 python 文档相矛盾,特别是它说
CTRL_C_EVENT 0 生成 CTRL+C 信号。无法为进程组生成此信号
以下站点提供了有关创建标志的更多信息: 进程创建标志。
In python 2.7 in windows according to the documentation you can send a CTRL_C_EVENT
(Python 2.7 Subprocess Popen.send_signal documentation).
However when I tried it I did not receive the expected keyboard interrupt in the subprocess.
This is the sample code for for the parent process:
# FILE : parentProcess.py
import subprocess
import time
import signal
CREATE_NEW_PROCESS_GROUP = 512
process = subprocess.Popen(['python', '-u', 'childProcess.py'],
stdin=subprocess.PIPE,
stdout=subprocess.PIPE,
stderr=subprocess.STDOUT,
universal_newlines=True,
creationflags=CREATE_NEW_PROCESS_GROUP)
print "pid = ", process.pid
index = 0
maxLoops = 15
while index < maxLoops:
index += 1
# Send one message every 0.5 seconds
time.sleep(0.5)
# Send data to the subprocess
process.stdin.write('Bar\n')
# Read data from the subprocess
temp = process.stdout.readline()
print temp,
if (index == 10):
# Send Keyboard Interrupt
process.send_signal(signal.CTRL_C_EVENT)
This is the sample code for the child proceess:
# FILE : childProcess.py
import sys
while True:
try:
# Get data from main process
temp = sys.stdin.readline()
# Write data out
print 'Foo ' + temp,
except KeyboardInterrupt:
print "KeyboardInterrupt"
If I run the file parentProcess.py I expect to get "Foo Bar" ten times then a "KeyboardInterrupt" followed by "Foo Bar" 4 times but I get "Foo Bar" 15 times instead.
Is there a way to get the CTRL_C_EVENT to behave as a keyboard interrupt just as SIGINT behaves in Linux?
After doing some reading I found some information that seems to contradic the python documentation regarding CTRL_C_EVENT, in particular it says that
CTRL_C_EVENT
0 Generates a CTRL+C signal. This signal cannot be generated for process groups
The following site provide more inforamtion about creation flags:
Process Creation Flags.
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(2)
这种子进程信号处理方法在 Linux 和 Windows 2008 上都适用,都使用 Python 2.7.2,但它使用 Ctrl-Break 而不是 Ctrl-C。请参阅 中有关进程组和 Ctrl-C 的说明http://msdn.microsoft.com/en-us/library/ms683155%28v=vs.85%29.aspx。
捕手.py:
投掷者.py:
This method of signal handling by subprocesses worked for me on both Linux and Windows 2008, both using Python 2.7.2, but it uses Ctrl-Break instead of Ctrl-C. See the note about process groups and Ctrl-C in http://msdn.microsoft.com/en-us/library/ms683155%28v=vs.85%29.aspx.
catcher.py:
thrower.py:
尝试使用
或
引用:
http://docs.activestate.com/activepython/2.5/ pywin3/win32process_CREATE_NEW_PROCESS_GROUP.html
http: //msdn.microsoft.com/en-us/library/ms683155%28v=vs.85%29.aspx
读取有关 dwProcessGroupId 的信息,groupid 应该与进程 id 相同
try with
or
references:
http://docs.activestate.com/activepython/2.5/pywin3/win32process_CREATE_NEW_PROCESS_GROUP.html
http://msdn.microsoft.com/en-us/library/ms683155%28v=vs.85%29.aspx
read info about dwProcessGroupId, the groupid should be the same of the process id