继续接着上一篇写。

运行时改变配置

在前一篇中曾经谈到,ini_set函数可以在php执行的过程中,动态修改php的部分配置。注意,仅仅是部分,并非所有的配置都可以动态修改。关于ini配置的可修改性,参见:http://php.net/manual/zh/configuration.changes.modes.php

我们直接进入ini_set的实现,函数虽然有点长,但是逻辑很清晰:

PHP_FUNCTION(ini_set)
{
char *varname, *new_value;
int varname_len, new_value_len;
char *old_value; if (zend_parse_parameters(ZEND_NUM_ARGS() TSRMLS_CC, "ss", &varname, &varname_len, &new_value, &new_value_len) == FAILURE) {
return;
} // 去EG(ini_directives)中获取配置的值
old_value = zend_ini_string(varname, varname_len + , ); /* copy to return here, because alter might free it! */
if (old_value) {
RETVAL_STRING(old_value, );
} else {
RETVAL_FALSE;
} // 如果开启了安全模式,那么如下这些ini配置可能涉及文件操作,需要要辅助检查uid
#define _CHECK_PATH(var, var_len, ini) php_ini_check_path(var, var_len, ini, sizeof(ini))
/* safe_mode & basedir check */
if (PG(safe_mode) || PG(open_basedir)) {
if (_CHECK_PATH(varname, varname_len, "error_log") ||
_CHECK_PATH(varname, varname_len, "java.class.path") ||
_CHECK_PATH(varname, varname_len, "java.home") ||
_CHECK_PATH(varname, varname_len, "mail.log") ||
_CHECK_PATH(varname, varname_len, "java.library.path") ||
_CHECK_PATH(varname, varname_len, "vpopmail.directory")) {
if (PG(safe_mode) && (!php_checkuid(new_value, NULL, CHECKUID_CHECK_FILE_AND_DIR))) {
zval_dtor(return_value);
RETURN_FALSE;
}
if (php_check_open_basedir(new_value TSRMLS_CC)) {
zval_dtor(return_value);
RETURN_FALSE;
}
}
} // 在安全模式下,如下这些ini受到保护,不会被动态修改
if (PG(safe_mode)) {
if (!strncmp("max_execution_time", varname, sizeof("max_execution_time")) ||
!strncmp("memory_limit", varname, sizeof("memory_limit")) ||
!strncmp("child_terminate", varname, sizeof("child_terminate"))
) {
zval_dtor(return_value);
RETURN_FALSE;
}
} // 调用zend_alter_ini_entry_ex去动态修改ini配置
if (zend_alter_ini_entry_ex(varname, varname_len + , new_value, new_value_len, PHP_INI_USER, PHP_INI_STAGE_RUNTIME, TSRMLS_CC) == FAILURE) {
zval_dtor(return_value);
RETURN_FALSE;
}
}

可以看到,除了一些必要的验证工作,主要就是调用zend_alter_ini_entry_ex。

我们继续跟进到zend_alter_ini_entry_ex函数中:

ZEND_API int zend_alter_ini_entry_ex(char *name, uint name_length, char *new_value, uint new_value_length, int modify_type, int stage, int force_change TSRMLS_DC) /* {{{ */
{
zend_ini_entry *ini_entry;
char *duplicate;
zend_bool modifiable;
zend_bool modified; // 找出EG(ini_directives)中对应的ini_entry
if (zend_hash_find(EG(ini_directives), name, name_length, (void **) &ini_entry) == FAILURE) {
return FAILURE;
} // 是否被修改以及可修改性
modifiable = ini_entry->modifiable;
modified = ini_entry->modified; if (stage == ZEND_INI_STAGE_ACTIVATE && modify_type == ZEND_INI_SYSTEM) {
ini_entry->modifiable = ZEND_INI_SYSTEM;
} // 是否强制修改
if (!force_change) {
if (!(ini_entry->modifiable & modify_type)) {
return FAILURE;
}
} // EG(modified_ini_directives)用于存放被修改过的ini_entry
// 主要用做恢复
if (!EG(modified_ini_directives)) {
ALLOC_HASHTABLE(EG(modified_ini_directives));
zend_hash_init(EG(modified_ini_directives), 8, NULL, NULL, 0);
} // 将ini_entry中的值,值的长度,可修改范围,保留到orig_xxx中去
// 以便在请求结束的时候,可以对ini_entry做恢复
if (!modified) {
ini_entry->orig_value = ini_entry->value;
ini_entry->orig_value_length = ini_entry->value_length;
ini_entry->orig_modifiable = modifiable;
ini_entry->modified = 1;
zend_hash_add(EG(modified_ini_directives), name, name_length, &ini_entry, sizeof(zend_ini_entry*), NULL);
} duplicate = estrndup(new_value, new_value_length); // 调用modify来更新XXX_G中对应的ini配置
if (!ini_entry->on_modify || ini_entry->on_modify(ini_entry, duplicate, new_value_length, ini_entry->mh_arg1, ini_entry->mh_arg2, ini_entry->mh_arg3, stage TSRMLS_CC) == SUCCESS) {
// 同上面,如果多次修改,则需要释放前一次修改的值
if (modified && ini_entry->orig_value != ini_entry->value) {
efree(ini_entry->value);
}
ini_entry->value = duplicate;
ini_entry->value_length = new_value_length;
} else {
efree(duplicate);
return FAILURE;
} return SUCCESS;
}

有3处逻辑需要我们仔细体会:

1)ini_entry中的modified字段用来表示该配置是否被动态修改过。一旦该ini配置发生修改,modified就会被置为1。上述代码中有一段很关键:

// 如果多次调用ini_set,则orig_value等始终保持最原始的值
if (!modified) {
ini_entry->orig_value = ini_entry->value;
ini_entry->orig_value_length = ini_entry->value_length;
ini_entry->orig_modifiable = modifiable;
ini_entry->modified = ;
zend_hash_add(EG(modified_ini_directives), name, name_length, &ini_entry, sizeof(zend_ini_entry*), NULL);
}

这段代码表示,不管我们先后在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在细节上的性能优化点。

恢复配置

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的恢复处理:

/* 7. Shutdown scanner/executor/compiler and restore ini entries */
zend_deactivate(TSRMLS_C);

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

zend_try {
zend_ini_deactivate(TSRMLS_C);
} zend_end_try();

具体来看看zend_ini_deactivate的实现:

ZEND_API int zend_ini_deactivate(TSRMLS_D) /* {{{ */
{
if (EG(modified_ini_directives)) {
// 遍历EG(modified_ini_directives)中这张表
// 对每一个ini_entry调用zend_restore_ini_entry_wrapper
zend_hash_apply(EG(modified_ini_directives), (apply_func_t) zend_restore_ini_entry_wrapper TSRMLS_CC); // 回收操作
zend_hash_destroy(EG(modified_ini_directives));
FREE_HASHTABLE(EG(modified_ini_directives));
EG(modified_ini_directives) = NULL;
}
return SUCCESS;
}

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

static int zend_restore_ini_entry_wrapper(zend_ini_entry **ini_entry TSRMLS_DC)
{
// zend_restore_ini_entry_wrapper就是zend_restore_ini_entry_cb的封装
zend_restore_ini_entry_cb(*ini_entry, ZEND_INI_STAGE_DEACTIVATE TSRMLS_CC);
return ;
} static int zend_restore_ini_entry_cb(zend_ini_entry *ini_entry, int stage TSRMLS_DC)
{
int result = FAILURE; // 只看修改过的ini项
if (ini_entry->modified) {
if (ini_entry->on_modify) {
// 使用orig_value,对XXX_G内的相关字段进行重新设置
zend_try {
result = ini_entry->on_modify(ini_entry, ini_entry->orig_value, ini_entry->orig_value_length, ini_entry->mh_arg1, ini_entry->mh_arg2, ini_entry->mh_arg3, stage TSRMLS_CC);
} zend_end_try();
}
if (stage == ZEND_INI_STAGE_RUNTIME && result == FAILURE) {
/* runtime failure is OK */
return ;
}
if (ini_entry->value != ini_entry->orig_value) {
efree(ini_entry->value);
} // ini_entry本身恢复到最原始的值
ini_entry->value = ini_entry->orig_value;
ini_entry->value_length = ini_entry->orig_value_length;
ini_entry->modifiable = ini_entry->orig_modifiable;
ini_entry->modified = ;
ini_entry->orig_value = NULL;
ini_entry->orig_value_length = ;
ini_entry->orig_modifiable = ;
}
return ;
}

逻辑都蛮清晰的,相信读者可以看明白。总结一下关于ini配置的恢复流程:

php_request_shutdown--->zend_deactivate--->zend_ini_deactivate--->zend_restore_ini_entry_wrapper--->zend_restore_ini_entry_cb

配置的销毁

在sapi生命周期结束的时候,比如apache关闭,cli程序执行完毕等等。一旦进入到这个阶段,之前所说的configuration_hash,EG(ini_directives)等都需要被销毁,其用到的内存空间需要被释放。

1,php会依次结束所有的模块,在每个模块的PHP_MSHUTDOWN_FUNCTION中调用UNREGISTER_INI_ENTRIES。UNREGISTER_INI_ENTRIES和REGISTER_INI_ENTRIES对应,但是UNREGISTER_INI_ENTRIES并不负责模块全局空间的释放,XXX_globals这块内存放在静态数据区上,无需人为回收。

UNREGISTER_INI_ENTRIES主要做的事情,是将某个模块的ini_entry配置从EG(ini_directives)表中删除。删除之后,ini_entry本身的空间会被回收,但是ini_entry->value不一定会被回收。

当所有模块的PHP_MSHUTDOWN_FUNCTION都调用UNREGISTER_INI_ENTRIES一遍之后,EG(ini_directives)中只剩下了Core模块的ini配置。此时,就需要手动调用UNREGISTER_INI_ENTRIES,来完成对Core模块配置的删除工作。

void php_module_shutdown(TSRMLS_D)
{
... // zend_shutdown会依次关闭除了Core之外的所有php模块
// 关闭时会调用各个模块的PHP_MSHUTDOWN_FUNCTION
zend_shutdown(TSRMLS_C); ... // 至此,EG(ini_directives)中只剩下了Core模块的配置
// 这里手动清理一下
UNREGISTER_INI_ENTRIES(); // 回收configuration_hash
php_shutdown_config();
    // 回收EG(ini_directives)
zend_ini_shutdown(TSRMLS_C);
...
}

当手动调用UNREGISTER_INI_ENTRIES完成之后,EG(ini_directives)已经不包含任何的元素,理论上讲,此时的EG(ini_directives)是一张空的hash表。

2,configuration_hash的回收发生在EG(ini_directives)之后,上面贴出的代码中有关于php_shutdown_config的函数调用。php_shutdown_config主要负责回收configuration_hash。

int php_shutdown_config(void)
{
// 回收configuration_hash
zend_hash_destroy(&configuration_hash); ... return SUCCESS;
}

注意zend_hash_destroy并不会释放configuration_hash本身的空间,同XXX_G访问的模块全局空间一样,configuration_hash也是一个全局变量,无需手动回收。

3,当php_shutdown_config完成时,只剩下EG(ini_directives)的自身空间还没被释放。因此最后一步调用zend_ini_shutdown。zend_ini_shutdown用于释放EG(ini_directives)。在前文已经提到,此时的EG(ini_directives)理论上是一张空的hash表,因此该HashTable本身所占用的空间需要被释放。

ZEND_API int zend_ini_shutdown(TSRMLS_D)
{
// EG(ini_directives)是动态分配出的空间,需要回收
zend_hash_destroy(EG(ini_directives));
free(EG(ini_directives));
return SUCCESS;
}

总结

用一张图大致描述一下和ini配置相关的流程:

深入理解php中的ini配置(2)的更多相关文章

  1. 深入理解php中的ini配置(1)

    这篇文章不会详细叙述某个ini配置项的用途,这些在手册上已经讲解的面面俱到.我只是想从某个特定的角度去挖掘php的实现机制,会涉及到一些php内核方面的知识:-) 使用php的同学都知道php.ini ...

  2. 【C# Task】理解Task中的ConfigureAwait配置同步上下文

    原文:https://devblogs.microsoft.com/dotnet/configureawait-faq/ 作者:Stephen 翻译:xiaoxiaotank 静下心来,你一定会有收获 ...

  3. shiro中INI配置

    4.1 根对象SecurityManager 从之前的Shiro架构图可以看出,Shiro是从根对象SecurityManager进行身份验证和授权的:也就是所有操作都是自它开始的,这个对象是线程安全 ...

  4. 深入理解 Laravel 中 config 配置加载原理

    Laravel的配置加载其实就是加载config目录下所有文件配置.如何过使用php artisan config:cache则会把加载的配置合并到一个配置文件中,下次请求就不会再去加载config目 ...

  5. 深入理解Java中配置环境变量

    深入理解Java中配置环境变量 配置的目的: 本来只在安装JDK的bin目下能运行java.exe,javac.exe,jar.exe,javadoc.exe等Java开发工具包命令,我们现在想让在所 ...

  6. windows中使用mysql配置my.ini时的坑

    windows中安装mysql的一般步骤: mysql版本:5.7.16 1.解压 2.把解压的文件夹bin目录地址添加到环境变量PATH里面 3.在文件加中添加配置文件my.ini——配置内容后面说 ...

  7. 跟开涛老师学shiro -- INI配置

    之前章节我们已经接触过一些INI配置规则了,如果大家使用过如spring之类的IoC/DI容器的话,Shiro提供的INI配置也是非常类似的,即可以理解为是一个IoC/DI容器,但是区别在于它从一个根 ...

  8. php.ini配置中文详解

    ;;;;;;;;;;; ; 警告 ; ;;;;;;;;;;; ; 此配置文件是对于新安装的PHP的默认设置. ; 默认情况下,PHP使用此配置文件安装 ; 此配置针对开发目的,并且*不是*针对生产环境 ...

  9. 第四章:shiro的INI配置

    4.1 根对象SecurityManager 从之前的Shiro架构图可以看出,Shiro是从根对象SecurityManager进行身份验证和授权的:也就是所有操作都是自它开始的,这个对象是线程安全 ...

随机推荐

  1. shell命令跟踪

    Linux Shell提供了两种方式来跟踪Shell脚本中的命令,以帮助我们准确的定位程序中存在的问题.下面的代码为第一种方式,该方式会将Shell脚本中所有被执行的命令打印到终端,并在命令前加&qu ...

  2. SQLite数据类型(学习必备)

    最近在学习android端的数据库,以下知识点作为备用- 一.存储种类和数据类型: SQLite将数据值的存储划分为以下几种存储类型:     NULL: 表示该值为NULL值.     INTEGE ...

  3. SQL Serever学习12——数据库的备份和还原

    公司的服务器奔溃了,事先没相应的保护措施,使得公司遭到了较大损失,为了以后不再出现类似事件,在系统中引入备份机制,使得数据库被破坏后损失降到最低. 数据的导出和导入 数据转换服务 数据转换服务DTS( ...

  4. 面向对象(基础oop)之继承总结

    大家好,我叫李京阳,,很高兴认识大家,之所以我想开一个自己的博客,就是来把自己所了解的知识点通过自己的话写一下,希望被博客园的朋友们点评和一起讨论一下,也希望从博客园中多认识一些软件开发人员!现在我开 ...

  5. centos文件/文件夹操作-检查磁盘、内存、cpu使用情况-vi操作命令

    Part1:CentOS文件/文件夹操作 1.新建文件夹 即创建目录 mkdir 文件名 新建一个名为test的文件夹在home下 vi source1 mkdir /home/test 注意:当创建 ...

  6. 传统的MapReduce框架慢在那里

    为什么之前的MapReduce系统比较慢 常理上有几个理由使得MapReduce框架慢于MPP数据库: 容错所引入的昂贵数据实体化(data materialization)开销. 孱弱的数据布局(d ...

  7. 1.Java设计模式-工厂模式

    1.简单工厂模式(Factory Method) 常用的工厂模式是静态工厂模式,利用static修饰方法,作为一种类似于常见的工具类Utils等辅助效果,一般情况下工厂类不需要实例化. //1.定义一 ...

  8. bnu 29378 Adidas vs Adivon 基础题

    Adidas vs Adivon Time Limit: 1000ms Memory Limit: 65536KB   64-bit integer IO format: %lld      Java ...

  9. K:求取两个数的最大公约数的两个算法

    相关介绍:  最大公因数,也称最大公约数.最大公因子,指两个或多个整数共有约数中最大的一个.a,b的最大公约数记为gcd(a,b).同样的,a,b,c的最大公约数记为gcd(a,b,c),多个整数的最 ...

  10. PAT 1032. Sharing

    其实就是链表求交: #include <iostream> #include <cstdio> #include <cstdlib> #include <un ...