在os.system("sleep ...")中,Python如何阻止信号?

pts*_*pts 5 python linux signals python-2.7

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

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

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

status=0
HANDLER
Run Code Online (Sandbox Code Playgroud)

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

但是,有subprocess.call:

import os, signal, subprocess
signal.signal(signal.SIGABRT, lambda *args: os.write(2, 'HANDLER\n'))
print 'cstatus=%r' % subprocess.call('sleep 5', shell=True)
Run Code Online (Sandbox Code Playgroud)

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

HANDLER
HANDLER
HANDLER
cstatus=0
Run Code Online (Sandbox Code Playgroud)

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

#include <errno.h>
#include <signal.h>
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <unistd.h>
static void handler(int signum) { (void)signum; write(2, "HANDLER\n", 8); }
int main(int argc, char **argv) {
  int got;
  struct sigaction sa;
  (void)argc; (void)argv;
  memset(&sa, 0, sizeof sa);
  sa.sa_handler = handler;
  if (0 != sigaction(SIGABRT, &sa, NULL)) return 3;
  got = system("sleep 5");
  return !printf("system=0x%x\n", got);
}
Run Code Online (Sandbox Code Playgroud)

信号提前交付:

HANDLER
HANDLER
HANDLER
system=0x0
Run Code Online (Sandbox Code Playgroud)

所以我推断魔术是在Python 2.7中,而不是在eglibc中.但魔术在哪里?基于strace输出并查看posix_system函数Modules/posixmodule.c,我无法弄清楚Python如何阻止信号直到os.system返回.

相关代码来自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);
}
Run Code Online (Sandbox Code Playgroud)

也许魔法在Py_BEGIN_ALLOW_THREADS

我是否正确理解我的Python信号处理程序(设置者signal.signal)不可能在os.system返回之前执行?

是因为信号处理程序被阻止(在Python级别,而不是在操作系统级别),直到Py_END_ALLOW_THREADS返回?

以下是Python代码的strace输出os.system:http://pastebin.com/Wjn9KBye

pil*_*row 4

也许魔法就在 PY_BEGIN_ALLOW_THREADS 中?

魔法主要在system于其本身。 system无法返回 EINTR,因此 libc 实现会煞费苦心地wait在子进程上恢复其“ing”。这意味着在使用 时os.system,在底层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
Run Code Online (Sandbox Code Playgroud)

当底层中断时,控制权确实返回到 python。waitOSError/EINTR 提示 python 查看是否有任何信号被触发,如果有,则调用用户提供的与该信号关联的代码块。(这就是解释器如何适应系统的信号语义:设置一个标志,并在“原子”Python 操作之间检查它,如果合适的话调用用户的代码。)