Dynamically modify ini configuration in php_php basics

1. Change configuration during runtime
As mentioned in the previous article, the ini_set function can dynamically modify some configurations of PHP during the execution of PHP. Note that this is only part of it, not all configurations can be modified dynamically. Regarding the modifiable ini configuration, see:http://php.net/manual/zh/configuration. changes.modes.php

We go directly to the implementation of ini_set. Although the function is a bit long, the logic is very clear:

As you can see, in addition to some necessary verification work, the main thing is to call zend_alter_ini_entry_ex.

We continue to follow up in the zend_alter_ini_entry_ex function:

There are three pieces of logic that we need to understand carefully:

1) The modified field in ini_entry is used to indicate whether the configuration has been dynamically modified. Once the ini configuration is modified, modified will be set to 1. There is a crucial section in the above code:

This code means that no matter how many times we call ini_set in the php code, only the first ini_set will enter this logic and set the orig_value. Starting from the second call to ini_set, this branch will not be executed again, because modified at this time has been set to 1. Therefore, ini_entry->orig_value always saves the configuration value before the first modification (that is, the most original configuration).

2) In order to make the configuration modified by ini_set take effect immediately, the on_modify callback function is required.

As mentioned in the previous article, on_modify is called to be able to update the module's global variables. Recall again, first of all, the configuration in the module global variables is no longer of string type. Use bool when it should use bool, and int when it should use int. Secondly, each ini_entry stores the address of the module's global variable and the corresponding offset, so that on_modify can quickly modify the memory. In addition, don't forget that after on_modify is called, ini_entry->value still needs to be further updated so that the configuration value in EG (ini_directives) is the latest.

3) A new hash table appears here, EG (modified_ini_directives).

EG (modified_ini_directives) is only used to store dynamically modified ini configurations. If an ini configuration is dynamically modified, then it exists in both EG (ini_directives) and EG (modified_ini_directives). Since each ini_entry is marked with a modified field, isn't it possible to traverse EG (ini_directives) to obtain all modified configurations?

The answer is yes. Personally, I feel that the EG (modified_ini_directives) here is mainly to improve performance, and it is enough to directly traverse the EG (modified_ini_directives). In addition, by deferring the initialization of EG (modified_ini_directives) to zend_alter_ini_entry_ex, you can also see the performance optimization points of PHP in details.

2. Restore configuration
The action time of ini_set is different from that of the php.ini file. Once the request execution ends, ini_set will become invalid. In addition, when the ini_restore function is called in our code, the configuration previously set through ini_set will also become invalid.

After each php request is executed, php_request_shutdown will be triggered. It and php_request_startup are two corresponding processes. If php is hooked under apache/nginx, php_request_shutdown will be called every time an http request is processed; if php is run in CLI mode, php_request_shutdown will also be called after the script is executed.

In php_request_shutdown, we can see the recovery processing for ini:

Entering zend_deactivate, you can further see that the zend_ini_deactivate function is called, and zend_ini_deactivate is responsible for restoring the PHP configuration.

Let’s take a closer look at the implementation of zend_ini_deactivate:

From the perspective of zend_hash_apply, the real task of restoring ini finally falls to the zend_restore_ini_entry_wrapper callback function.

The logic is quite clear, I believe readers can understand it. Summarize the recovery process of ini configuration:

3. Destruction of configuration
At the end of the sapi life cycle, for example, apache is shut down, the cli program is executed, etc. Once entering this stage, the previously mentioned configuration_hash, EG (ini_directives), etc. need to be destroyed, and the memory space used by them needs to be released.

1. PHP will end all modules in sequence and call UNREGISTER_INI_ENTRIES in PHP_MSHUTDOWN_FUNCTION of each module. UNREGISTER_INI_ENTRIES corresponds to REGISTER_INI_ENTRIES, but UNREGISTER_INI_ENTRIES is not responsible for releasing the global space of the module. The memory of XXX_globals is placed in the static data area and does not need to be manually recycled.

The main thing UNREGISTER_INI_ENTRIES does is to delete the ini_entry configuration of a certain module from the EG (ini_directives) table. After deletion, the space of ini_entry itself will be recycled, but ini_entry->value may not be recycled.

After PHP_MSHUTDOWN_FUNCTION of all modules calls UNREGISTER_INI_ENTRIES once, only the ini configuration of the Core module is left in EG (ini_directives). At this time, you need to manually call UNREGISTER_INI_ENTRIES to complete the deletion of the Core module configuration.

When the manual call to UNREGISTER_INI_ENTRIES is completed, EG (ini_directives) no longer contains any elements. Theoretically, EG (ini_directives) at this time is an empty hash table.

2. The recycling of configuration_hash occurs after EG (ini_directives). The code posted above contains the function call about php_shutdown_config. php_shutdown_config is mainly responsible for recycling configuration_hash.

Note that zend_hash_destroy does not release the space of configuration_hash itself. Like the global space of the module accessed by XXX_G, configuration_hash is also a global variable and does not need to be manually recycled.

3. When php_shutdown_config is completed, only the own space of EG (ini_directives) has not been released. So the last step calls zend_ini_shutdown. zend_ini_shutdown is used to release EG (ini_directives). As mentioned above, the EG (ini_directives) at this time is theoretically an empty hash table, so the space occupied by the HashTable itself needs to be released.

4. Summary
Use a picture to roughly describe the process related to ini configuration: