在os.system(“sleep …”)中,Python如何阻止信号？

当我在Ubuntu 12.04上使用os.system运行这个Python脚本时：

import os,signal
signal.signal(signal.SIGABRT,lambda *args: os.write(2,'HANDLER\n'))
print 'status=%r' % os.system('sleep 5')

,然后我在5秒内多次将SIGABRT发送到脚本进程,我得到以下输出：

status=0
HANDLER

这表明信号传递被阻止直到睡眠5退出,然后仅传递单个信号.

但是,使用subprocess.call：

import os,signal,subprocess
signal.signal(signal.SIGABRT,'HANDLER\n'))
print 'cstatus=%r' % subprocess.call('sleep 5',shell=True)

,所有个别信号都提前交付：

HANDLER
HANDLER
HANDLER
cstatus=0

为了区分glibc中的魔法和Python中的魔法,我在C中重写了Python脚本,因此os.system成为了system(3)：

#include


信号提前交付：

HANDLER
HANDLER
HANDLER
system=0x0

所以我推断魔术是在Python 2.7中,而不是在eglibc中.但魔术在哪里？基于strace输出并查看Modules / posixmodule.c中的posix_system函数,我无法弄清楚在os.system返回之前Python如何阻塞信号.
Modules / posixmodule.c中的相关代码：

static PyObject *posix_system(PyObject *self,PyObject *args) {
  char *command;
  long sts;
  if (!PyArg_ParseTuple(args,"s:system",&command)) return NULL;
  Py_BEGIN_ALLOW_THREADS
  sts = system(command);
  Py_END_ALLOW_THREADS  
  return PyInt_FromLong(sts);
}

也许神奇的是在Py_BEGIN_ALLOW_THREADS？
我是否正确理解我的Python信号处理程序(由signal.signal设置)在os.system返回之前不可能执行？
是因为信号处理程序被阻止(在Python级别,而不是在操作系统级别),直到Py_END_ALLOW_THREADS返回？
以下是使用os.system：http://pastebin.com/Wjn9KBye的Python代码的strace输出


最佳答案


Maybe the magic is in PY_BEGIN_ALLOW_THREADS?

神奇主要在system本身.系统无法返回EINTR,因此libc实现很难恢复对子进程的等待.这意味着在使用os.system时,控件永远不会返回到python,直到底层系统完成,因此不会及时调用python信号处理机制.
但是,subprocess.call基本上是这样做的：

# Compare subprocess.py:Popen/_eintr_retry_call(os.waitpid,self.pid,0)
while True:
  try:
    return os.waitpid(the_child_pid,0)
  except OSError,e:
    if e.errno == errno.EINTR:  # signal.signal() handler already invoked
      continue
    raise

当底层等待被中断时,控件确实返回到python. OSError / EINTR提示python查看是否有任何信号被触发,如果是,则调用与该信号关联的用户提供的代码块. (这就是解释器如何调整系统的信号语义：设置一个标志,并在“原子”python操作之间进行检查,如果合适的话,调用用户的代码.)
版权声明：本文内容由互联网用户自发贡献，该文观点与技术仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容， 请发送邮件至 dio@foxmail.com 举报，一经查实，本站将立刻删除。

在os.system(“sleep …”)中,Python如何阻止信号？

相关推荐