PHP内核之动态修改PHP.INI

运行时改变配置

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

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

/* {{{ proto string ini_set(string varname, string newvalue)
   Set a configuration option, returns false on error and the old value of the configuration option on success */
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 + 1, 0);

	/* copy to return here, because alter might free it! */
	if (old_value) {
		RETVAL_STRING(old_value, 1);
	} else {
		RETVAL_FALSE;
	}

// 如果开启了安全模式，那么如下这些ini配置可能涉及文件操作，需要要辅助检查uid
#define _CHECK_PATH(var, var_len, ini) php_ini_check_path(var, var_len, ini, sizeof(ini))
	/* open basedir check */
	if (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 (php_check_open_basedir(new_value TSRMLS_CC)) {
				zval_dtor(return_value);
				RETURN_FALSE;
			}
		}
	}

	// 调用zend_alter_ini_entry_ex去动态修改ini配置
	if (zend_alter_ini_entry_ex(varname, varname_len + 1, new_value, new_value_len, PHP_INI_USER, PHP_INI_STAGE_RUNTIME, 0 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) { /* we already changed the value, free the changed 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 = 1;
		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 1;
}
/* }}} */

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 {
			/* even if on_modify bails out, we have to continue on with restoring,
				since there can be allocated variables that would be freed on MM shutdown
				and would lead to memory corruption later ini entry is modified again */
				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 1;
		}
		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 = 0;
		ini_entry->orig_value = NULL;
		ini_entry->orig_value_length = 0;
		ini_entry->orig_modifiable = 0;
	}
	return 0;
}
/* }}} */

逻辑都蛮清晰的，相信读者可以看明白。总结一下关于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。

/* {{{ php_shutdown_config
 */
int php_shutdown_config(void)
{
	zend_hash_destroy(&configuration_hash);		// 回收configuration_hash
	if (php_ini_opened_path) {
		free(php_ini_opened_path);
		php_ini_opened_path = NULL;
	}
	if (php_ini_scanned_files) {
		free(php_ini_scanned_files);
		php_ini_scanned_files = NULL;
	}
	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配置相关的流程：