| Both sides previous revisionPrevious revisionNext revision | Previous revisionNext revisionBoth sides next revision |
| internals:extensions [2013/04/10 13:29] – jpauli | internals:extensions [2013/04/10 15:08] – jpauli |
|---|
| 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 | 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. | ''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 | Dont be fooled here, it's not the activate() function wich is triggered from Zend extensions, but the startup() function |
| |
| ===== Extensions lifetime ===== | ===== Extensions lifetime ===== |
| Zend extensions come after, and their ''deactivate()'' function is called | 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 | 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 ===== | ===== Main schema ===== |
| | |
| | {{:internals:extensions_lifetime.png?200|}} |