在这个示例程序中,第一个SIGQUIT似乎什么都不做,但第二个sigquit打印“SIGQUIT Handler”和s.accept()会抛出一个Interrupted系统调用异常.
from signal import *
from socket import *
import sys
def sigquitHandler(signum,frame):
print("SIGQUIT Handler")
s = socket()
s.bind(("0.0.0.0",int(sys.argv[1])))
s.listen(5)
signal(SIGQUIT,sigquitHandler)
siginterrupt(SIGQUIT,False)
client,addr = s.accept() # Or any syscall that blocks
client.close()
s.close()
我在这里误会了什么？
编辑：这是我无法弄清楚的其他东西,在这个程序中,SIGQUIT中断了select().这应该发生吗？
from signal import *
import select
import sys
def sigquitHandler(signum,frame):
print("SIGQUIT Handler")
signal(SIGQUIT,False)
select.select([sys.stdin],[],[])
解决方法
我的猜测是你正在使用SYSV,在这种情况下,信号处理器返回后信号处理被重置为SIG_DFL(经典信号处理).在SYSV上,您需要在处理程序中调用signal以重新安装该处理程序.
Python或多或少提供了BSD风格的信号处理.因此,在SYSV OS上,Python必须通过信号管理信号处理程序的重新安装.现在,根据XP doco for siginterrupt：
Note that installing a signal handler
with signal() will reset the restart
behavIoUr to interruptible by
implicitly calling siginterrupt() with
a true flag value for the given
signal.
你去吧 – 如果Python自动重新安装你的信号处理程序(提供像语义一样的BSD),它可能会以隐式调用siginterrupt(1)的方式这样做.
当然,我的猜测可能是错的.
你可以通过像这样定义sigquitHandler来解决这个问题：
def sigquitHandler(signum,frame):
print("SIGQUIT Handler")
siginterrupt(SIGQUIT,False)
这取决于Python何时以及如何恢复信号处置.
编辑
将siginterrupt(SIGQUIT,False)添加到信号处理程序没有任何影响.
编辑2
在Python2.6源代码中进行了一些讨论之后,它清楚地表明这不仅仅是一个SYSV问题.它也会影响BSD系统.
