php中动态修改ini配置(3)

这段代码表示，不管我们先后在php代码中调用几次ini_set，只有第一次ini_set时才会进入这段逻辑，设置好orig_value。从第二次调用ini_set开始，便不会再次执行这段分支，因为此时的modified已经被置为1了。因此，ini_entry->orig_value始终保存的是第一次修改之前的配置值（即最原始的配置）。

2）为了能使ini_set修改的配置立即生效，需要on_modify回调函数。

如前一篇文中所述，调用on_modify是为了能够更新模块的全局变量。再次回忆下，首先，模块全局变量中的配置已经不是字符串类型了，该用bool用bool、该用int用int。其次，每一个ini_entry中都存储了该模块全局变量的地址以及对应的偏移量，使得on_modify可以很迅速的进行内存修改。此外不要忘记，on_modify调用完了之后，仍需进一步更新ini_entry->value，这样EG(ini_directives)中的配置值就是最新的了。

3）这里出现了一张新的hash表，EG(modified_ini_directives)。

EG(modified_ini_directives)只用于存放被动态修改过的ini配置，如果一个ini配置被动态修改过，那么它既存在于EG(ini_directives)中，又存在于EG(modified_ini_directives)中。既然每一个ini_entry都有modified字段做标记，那岂不是可以遍历EG(ini_directives)来获得所有被修改过的配置呢？

答案是肯定的。个人觉得，这里的EG(modified_ini_directives)主要还是为了提升性能，酱直接遍历EG(modified_ini_directives)就足够了。此外，把EG(modified_ini_directives)的初始化推迟到zend_alter_ini_entry_ex中，也可以看出php在细节上的性能优化点。

2，恢复配置
ini_set的作用时间和php.ini文件的作用时间是不一样的，一旦请求执行结束，则ini_set会失效。此外，当我们代码中调用了ini_restore函数，则之前通过ini_set设置的配置也会失效。

每一个php请求执行完毕之后，会触发php_request_shutdown，它和php_request_startup是两个相对应过程。如果php是挂接在apache/nginx下，则每处理完一个http请求，就会调用php_request_shutdown；如果php以CLI模式来运行，则脚本执行完毕之后，也会调用php_request_shutdown。

在php_request_shutdown中，我们可以看到针对ini的恢复处理：

进入zend_deactivate，可以进一步看到调用了zend_ini_deactivate函数，由zend_ini_deactivate来负责将php的配置进行恢复。

具体来看看zend_ini_deactivate的实现：

从zend_hash_apply来看，真正恢复ini的任务最终落地到了zend_restore_ini_entry_wrapper回调函数。