因为主线程执行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。
如图所示，
