php脚本运行时的超时机制详解
在做php开发的时候，经常会设置max_input_time、max_execution_time，用来控制脚本的超时时间。但却从来没有思考过背后的原理。
趁着这两天有空，研究一下这个问题。
超时配置
php的ini配置如何起作用，这是一个老生常谈的话题了。
首先，我们在php.ini里进行配置。当php启动的时候（php_module_startup阶段），会尝试读取ini文件并解析。解析过程简单来说，是分析ini文件，提取出其中合法的键值对，并保存到configuration_hash表。
ok，然后php会进一步调用zend_startup_extensions来启动各个模块（包含php core模块，以及所有需要加载的扩展）。各个模块的启动函数中，会完成register_ini_entries动作。register_ini_entries负责将模块对应的一些配置从configuration_hash表取出，然后调用处理函数，最终将处理完的值存入模块的globals变量。
max_input_time、max_execution_time这两个配置属于php core模块。对于php core来说，register_ini_entries依然发生在php_module_startup中。同样属于php core模块的配置还有expose_php、display_errors、memory_limit等等...
示意图如下：
---->php_module_startup----------->php_request_startup---->
|
|
|-->register_ini_entries
|
|
|-->zend_startup_extensions
| |
| |-->zm_startup_date
| | |-->register_ini_entries
| |
| |-->zm_startup_json
| | |-->register_ini_entries
|
|
|-->do otherthings
上面说到对于不同的配置，register_ini_entries会调用不同的函数来处理。我们直接来看max_execution_time对应的函数：
static php_ini_mh(onupdatetimeout)
{
// php启动阶段走这里
if (stage == php_ini_stage_startup) {
// 将超时设置保存到eg(timeout_seconds)中
eg(timeout_seconds) = atoi(new_value);
return success;
}
// php执行过程中的ini set则走这里
zend_unset_timeout(tsrmls_c);
eg(timeout_seconds) = atoi(new_value);
zend_set_timeout(eg(timeout_seconds), 0);
return success;
}
暂时只看上半截，因为我们目前只需关注php的启动阶段，该函数行为很简单，将max_execution_time存入了eg(timeout_seconds)。
至于max_input_time，并没有特殊的处理函数，默认是会将max_input_time存入存入pg(max_input_time)。
因此，当register_ini_entries完成，发生的是：
max_execution_time ----> 存入eg(timeout_seconds)
max_input_time ----> 存入pg(max_input_time)
请求超时控制
现在我们搞清楚php的启动阶段发生了什么，继续来看php在实际处理请求的时候，如何管理超时。
在php_request_startup函数中有如下代码：
if (pg(max_input_time) == -1) {
zend_set_timeout(eg(timeout_seconds), 1);
} else {
zend_set_timeout(pg(max_input_time), 1);
}
php_request_startup的时机很讲究。
以cgi为例，只有当php已经从cgi拿到了原始请求以及一些cgi的环境变量之后，php_request_startup才会被调用。上面这段代码实际执行的时候，由于请求已经拿到，所以sg(request_info)处于准备就绪状态，但是php中的$_get，$_post，$_file等超全局变量尚未生成。
从代码上理解：
1、如果用户将max_input_time配做-1，或没有配置，那么脚本的生命周期就只受eg(timeout_seconds)约束。
2、否则，请求启动阶段的超时控制，受pg(max_input_time)约束。
3、zend_set_timeout函数负责设置定时器。一旦指定时间过去，定时器会通知php进程。zend_set_timeout下文会具体分析。
php_request_startup完成，则进入php的实际执行阶段，即php_execute_script。在php_execute_script中可以看到：
// 设定执行超时
if (pg(max_input_time) != -1) {
#ifdef php_win32
zend_unset_timeout(tsrmls_c); // 关闭之前的定时器
#endif
zend_set_timeout(ini_int("max_execution_time"), 0);
}
// 进入执行
retval = (zend_execute_scripts(zend_require tsrmls_cc, null, 3, prepend_file_p, primary_file, append_file_p) == success);
ok，假如代码执行到这里，尚未发生max_input_time超时，则会重新指定max_execution_time的超时。
同样也是采取调用zend_set_timeout，并传入max_execution_time。特别注意一下，windows下面的需要显式调用zend_unset_timeout关闭原来的定时器，而linux下不需要。这是由于两个平台的定时器实现原理不同导致的，下文也会详细展开叙述。
最后用一张图表示超时控制的流程，左侧的case表明用户既配置了max_input_time，又配置了max_execution_time。而右侧的区别在于用户仅仅配置了max_execution_time：
zend_set_timeout
前文提到，zend_set_timeout函数用来设置定时器。具体来看下实现：
void zend_set_timeout(long seconds, int reset_signals) /* {{{ */
{
tsrmls_fetch();
// 赋值
eg(timeout_seconds) = seconds;
#ifdef zend_win32
if(!seconds) {
return;
}
// 启动定时器线程
if (timeout_thread_initialized == 0 && interlockedincrement(&timeout_thread_initialized) == 1) {
/* we start up this process-wide thread here and not in zend_startup(), because if zend
* is initialized inside a dllmain(), you're not supposed to start threads from it.
*/
zend_init_timeout_thread();
}
// 向线程发送wm_register_zend_timeout消息
postthreadmessage(timeout_thread_id, wm_register_zend_timeout, (wparam) getcurrentthreadid(),
(lparam) seconds);
#else
// linux平台下
struct itimerval t_r; /* timeout requested */
int signo;
if (seconds) {
t_r.it_value.tv_sec = seconds;
t_r.it_value.tv_usec = t_r.it_interval.tv_sec = t_r.it_interval.tv_usec = 0;
// 设置定时器，seconds秒后会发送sigprof信号
setitimer(itimer_prof, &t_r, null);
}
signo = sigprof;
if (reset_signals) {
sigset_t sigset;
// 设置sigprof信号对应的处理函数为zend_timeout
signal(signo, zend_timeout);
// 防屏蔽
sigemptyset(&sigset);
sigaddset(&sigset, signo);
sigprocmask(sig_unblock, &sigset, null);
}
#endif
}
上述实现基本上可以完全分成两种平台：
先看linux：
linux下的定时器要容易许多，调用setitimer函数就行，此外，zend_set_timeout还设定了sigprof信号的handler为zend_timeout。
注意，调用setitimer的时候，将it_interval设置成0，表明这个定时器只触发一次，而不会每隔一段时间触发一次。setitimer可以以三种方式计时，php中采用的是itimer_prof，它同时计算了用户代码和内核代码的执行时间。一旦时间到了，会产生sigprof信号。
当php进程接收到sigprof信号，不管当前正在执行什么，都会跳转进入到zend_timeout。zend_timeout才是实际处理超时的函数。
再看windows：
首先会启动一个子线程，该线程主要用于设置定时器，同时维护eg(timed_out)变量。
子线程一旦生成，主线程便会向子线程发送一条消息：wm_register_zend_timeout。子线程接收到wm_register_zend_timeout之后，产生一个定时器并开始计时。同时，子线程会设置eg(timed_out) = 0。这很重要！windows平台下正是通过判断eg(timed_out)是否为1，来决定是否超时。
如果定时器到时间了，子线程收到wm_timer消息，则取消定时器，并且设置eg(timed_out) = 1。
如果需要关闭定时器，则子线程会收到wm_unregister_zend_timeout消息。关闭定时器，并不会改变eg(timed_out)。
相关代码还是很清晰的：
static lresult callback zend_timeout_wndproc(hwnd hwnd, uint message, wparam wparam, lparam lparam)
{
switch (message) {
case wm_destroy:
postquitmessage(0);
break;
// 生成一个定时器，开始计时
case wm_register_zend_timeout:
/* wparam is the thread id pointer, lparam is the timeout amount in seconds */
if (lparam == 0) {
killtimer(timeout_window, wparam);
} else {
settimer(timeout_window, wparam, lparam*1000, null);
eg(timed_out) = 0;
}
break;
// 关闭定时器
case wm_unregister_zend_timeout:
/* wparam is the thread id pointer */
killtimer(timeout_window, wparam);
break;
// 超时了，也需关闭定时器
case wm_timer: {
killtimer(timeout_window, wparam);
eg(timed_out) = 1;
}
break;
default:
return defwindowproc(hwnd, message, wparam, lparam);
}
return 0;
}
根据上文描述，最终都是需要跳转到zend_timeout来处理超时的。那windows下如何进入zend_timeout呢？
window下仅在execute函数中（zend_vm_execute.h刚开始的地方），可以看到调用zend_timeout：
while (1) {
int ret;
#ifdef zend_win32
if (eg(timed_out)) { // windows下的超时，执行每条opcode之前都判断是否需要调用zend_timeout
zend_timeout(0);
}
#endif
if ((ret = opline->handler(execute_data tsrmls_cc)) > 0) {
...
}
}
上述代码可以看到：
在windows下，每执行完成一条opcode指令，就会进行一次超时判断。
因为主线程执行opcode的同时，子线程可能已经发生超时，而windows并没有什么机制可以让主线程停止手头的工作，直接跳入zend_timeout。所以只好利用子线程先将eg(timed_out)设置为1，然后主线程在等到当前opcode执行完成、进入下一条opcode之前，判断一下eg(timed_out)再调用zend_timeout。
因此准确的讲，windows的超时，其实是有一点点延时的。至少在某一个opcode执行的过程中，无法被打断。当然，正常情况下，单条opcode的执行时间会很短。但是可以很容易人为构造出一些很耗时的函数，使得function call需要等待较长时间。此时，如果子线程判断出超时了，则还需要经过漫长的等待，直到主线程完成该条opcode之后，才能调用zend_timeout。
zend_unset_timeout
void zend_unset_timeout(tsrmls_d) /* {{{ */
{
#ifdef zend_win32
// 通过发送wm_unregister_zend_timeout消息来关闭定时器
if(timeout_thread_initialized) {
postthreadmessage(timeout_thread_id, wm_unregister_zend_timeout, (wparam) getcurrentthreadid(), (lparam) 0);
}
#else
if (eg(timeout_seconds)) {
struct itimerval no_timeout;
no_timeout.it_value.tv_sec = no_timeout.it_value.tv_usec = no_timeout.it_interval.tv_sec = no_timeout.it_interval.tv_usec = 0;
// 全置0，相当于关闭定时器
setitimer(itimer_prof, &no_timeout, null);
}
#endif
}
zend_unset_timeout同样分成两种平台的实现。
先看linux：
linux下的关闭定时器也很简单。只要将struct itimerval中的4个值都设置为0，就行了。
再看windows：
由于windows是利用一个独立的线程来计时。因此，zend_unset_timeout会向该线程发送wm_unregister_zend_timeout消息。wm_unregister_zend_timeout对应的动作是去调用killtimer来关闭定时器。注意，线程本身并不退出。
前文留下了一个问题，在php_execute_script中，windows下面要显示调用zend_unset_timeout来关闭定时器，而linux下不需要。因为对于一个linux进程来说，只能存在一个setitimer定时器。也就是说，重复调用setitimer，后面的定时器会直接覆盖前面的。
zend_timeout
zend_api void zend_timeout(int dummy) /* {{{ */
{
tsrmls_fetch();
if (zend_on_timeout) {
zend_on_timeout(eg(timeout_seconds) tsrmls_cc);
}
zend_error(e_error, "maximum execution time of %d second%s exceeded", eg(timeout_seconds), eg(timeout_seconds) == 1 ? "" : "s");
}
如前文所述，zend_timeout是实际处理超时的函数。它的实现也很简单。
如果有配置exit_on_timeout，则zend_on_timeout会尝试调用sapi_terminate_process关闭sapi进程。如果无需exit_on_timeout，则直接进入zend_error进行出错处理。大部分情况下，我们并不会设置exit_on_timeout，毕竟我们期望的是虽然一个请求超时了，但是进程仍然保留下来，服务下一个请求。
zend_error除了会打印错误日志，还会利用longjump跳转到boilout指定的栈帧，一般是zend_end_try或者zend_catch宏所在的地方。关于longjump，可以另起一个话题，本文就不具体叙述了。在php_execute_script里面，zend_error会使得程序跳转到zend_end_try的位置然后继续执行。继续执行是指，会调用php_request_shutdown等函数来完成收尾工作。
直到这里，php脚本的超时机制算是讲清楚了。
最后来看一个疑似php内核的bug。
windows下max_input_time的bug
回忆一下，之前有提到windows下只有一个地方调用了zend_timeout，就是execute函数里，准确讲是每条opcode执行之前。
那么，假如发生max_input_time类型的超时，即使子线程将eg(timed_out)被置为1，也得延迟到execute中才能进行超时处理。貌似一切正常。
而问题的关键之处便在于，我们并不能保证主线程执行到execute时，eg(timed_out)任然为1。一旦进入execute之前，eg(timed_out)被子线程修改成0，那么max_input_time类型的超时就永远不会被handle了。
为何eg(timed_out)会被子线程又修改为0呢？原因在于：php_execute_script中，调用了zend_set_timeout(ini_int("max_execution_time"), 0)来设置定时器。
zend_set_timeout会向子线程发送wm_register_zend_timeout消息。子线程收到此消息，除了创建定时器之外，还会设置eg(timed_out) = 0（详见上文截取的zend_timeout_wndproc代码片段）。由于线程执行的不确定性，因此不能够判断主线程执行到execute的时候，子线程是否已接收到消息并设置eg(timed_out)为0。
如图所示，
如果execute中的判断发生在红线标注的时间点，则eg(timed_out)为1，execute会调用zend_timeout做超时处理。
如果execute中的判断发生在蓝线标注的时间点，则eg(timed_out)已被重置为0，max_input_time超时被彻底掩盖。