基于linux信号的timeout装饰器

在做基于ray的分布式任务处理时，偶尔遇到由于ray集群不稳定导致的长时间连接不上，进而导致程序卡死,无法向后端返回任务状态的情况。但是ray的初始化函数本身未实现超时机制，因此设计基于多线程+信号的timeout装饰器，当连接超时时，向后端返回异常状态。

这里之所以要起新线程去初始化ray，是为了保证主线程可以随时处理sigalrm信号，因为linux信号是一种软中断，linux内核的信号处理时机是在程序由内核态切换为用户态时，如果被监控程序未发生内核态到用户态的切换，那么即使内核向进程发出了信号，信号也只会入队，不会触发信号处理函数的执行。

import ray
import threading
import signal

def timeout(seconds=5, hint=''):
    def handler(signo, frame):
        raise Exeption('{}执行超时! time out={}'.format(hint, seconds)
    def wrap(func):
        def dec(*args, **kwargs):
            signal.signal(signal.SIGALRM, handler)
            signal.alarm(seconds)
            res = func(*args, **kwargs)
            signal.alarm(0)
            return res
        return dec
    return wrap

@timeout(3, '初始化计算资源')
def init_calculation_resources():
    kwargs  = {...}
    t = threading.Thread(target=ray.init, kwargs=(kwargs))
    t.start()
    t.join()

 linux对信号的处理机制：

信号号称所谓软中断，事实上，还是没有真正的硬件中断那样能随时改变cpu的执行流，

硬件中断之所以能一发生就得到处理是因为处理器在每个指令周期的结尾都会去检查中断，这种粒度是很细的，

但是信号的实现只是在进程的task_struct里面有一个成员用于标识当前收到了哪些信号？

而这个成员的检查显然只能在特定时间点：从内核模式返回到用户模式的时候

可以想象，当进程从一个硬件中断中返回、从系统调用中返回或者正在休眠或者刚刚得到了调度，都是从内核态返回用户态的时机

这时候就会检查pending signals，注意信号处理函数的调用也看成是在内核态的，也就是如果累计了多个信号会一直处理完才返回用户态。

所以永远不要指望你所发送的信号能像硬件中断那般随时处理！