| Both sides previous revisionPrevious revisionNext revision | Previous revisionNext revisionBoth sides next revision |
| internals:extensions [2013/04/10 12:54] – jpauli | internals:extensions [2013/04/10 15:08] – jpauli |
|---|
| ==== Activating PHP extensions ==== | ==== Activating PHP extensions ==== |
| After registration, comes activation, and here is the step where the engine will effectively sort the PHP extensions in an order that make the dependencies be activated in a specific order. | After registration, comes activation, and here is the step where the engine will effectively sort the PHP extensions in an order that make the dependencies be activated in a specific order. |
| **PHP extensions are activated before Zend extensions** | PHP extensions are activated before Zend extensions |
| |
| ''zend_startup_modules()'' does the job of activating PHP extensions. It starts by sorting them in the ''module_registry'' Hashtable calling a sorting callback. This sort process will check for dependencies requirement, and sort the registry in a way that dependency requirements are activated first. | ''zend_startup_modules()'' does the job of activating PHP extensions. It starts by sorting them in the ''module_registry'' Hashtable calling a sorting callback. This sort process will check for dependencies requirement, and sort the registry in a way that dependency requirements are activated first. |
| It checks the extension field ''module_started'' , just a flag not to activate the same extension more than once. It then checks dependencies against requirements. If an extension requires another to be registered before itself and it's not the case, then an error will show up. | It checks the extension field ''module_started'' , just a flag not to activate the same extension more than once. It then checks dependencies against requirements. If an extension requires another to be registered before itself and it's not the case, then an error will show up. |
| Note that conflicts requirements have already been checked against, at extension loading (see last chapter) | Note that conflicts requirements have already been checked against, at extension loading (see last chapter) |
| After that, ''module_startup_func()'' is called on the extension, this is known as beeing the "MINIT process" | After that, the extension globals are registered (call to ''globals_ctor()'' on the extension) and ''module_startup_func()'' is called on the extension, this is known as beeing the "MINIT process" |
| | |
| | ==== Activating Zend extensions ==== |
| | Zend extensions are then activated **after** PHP extensions |
| | ''zend_extension_startup()'' is called on the Zend extensions registry |
| | Remember that Zend extensions are never sorted in any way. You must then declare them in the FIFO order in php.ini. The engine wont touch your declaration order |
| | ''zend_extension_startup()'' just calls for the ''startup()'' function on Zend extensions, and appends a declaration message in the Zend phpinfo() message "With module XXX" showing to end user the Zend extension is both registered, and activated. |
| | Dont be fooled here, it's not the activate() function wich is triggered from Zend extensions, but the startup() function |
| | |
| | ===== Extensions lifetime ===== |
| | You may know PHP's lifetime. Very basically, ''php_module_startup()'', then ''php_request_startup()'' at each request, followed by ''php_request_shutdown()'' , and then when PHP has to die : ''php_module_shutdown()''. |
| | We already detailed php_module_startup() previously, to show how both PHP extensions and Zend extensions live into this stage. |
| | |
| | ==== Request startup ==== |
| | Zend extensions come first, and their ''activate()'' function is called |
| | PHP extensions come second, and their ''request_startup_func()'' is called, this is known as beeing the "RINIT" stage |
| | |
| | ==== Request shutdown ==== |
| | PHP extensions come first, and their ''request_shutdown_func()'' is called, this is known as beeing the "RSHUTDOWN" stage |
| | Zend extensions come after, and their ''deactivate()'' function is called |
| | A third hook is called : ''post_deactivate_func()'', for each PHP extensions. PHP extensions are here given a chance to do some work after Zend extensions have all shut down |
| | |
| | ==== PHP shutdown ==== |
| | PHP is ending, so as we are clean guys, we wrote code for PHP to clean up its environment in a right way and don't rely on the process terminating to destroy all the environment. |
| | PHP extensions are first destroyed. This is done internally by relying on the Hashtable functionnalities. As the ''module_registry'' containing all the PHP extensions is a Hashtable, when it is constructed for the first time, a destructor is registered. This one is called here. It is ''module_destructor()'' |
| | It calls ''module_shutdown_func()'' on each extension, this is called the "MSHUTDOWN" stage. Then it destroys the extension globals calling ''globals_dtor()'' and finally it unregisters the PHP functions the extension may have registered at startup. |
| | Finally, if the extension were to be loaded with ''dlopen()'' (not a statically compiled extension), it is then dlunload()'ed except if the env variable ZEND_DONT_UNLOAD_MODULES is used (usefull for debugging modules with valgrind, for example) |
| | |
| | After PHP extensions have all been shut down and unloaded, Zend extensions will be. |
| | ''zend_shutdown_extensions()'' is called, and its job is just to trigger ''shutdown()'' on each Zend extension (and destroy it from the main Zend extension registry) |
| | |
| | ===== Main schema ===== |
| | |
| | {{:internals:extensions_lifetime.png?200|}} |