The PHP module is the usual PHP extension.
This type includes the vast majority of extensions in PHP. All that is connected in php.ini
with the instruction extension=some_library.so
is what they are.
Zend extension
Extensions of this type are extremely small, but they are no less in demand.
In the article, I surveyed, quite at the top, I’ll tell you how these two types of extensions differ.
They differ only in the connection method.
Normal extensions are connected via php.ini
using the instructions:extension=some_extension.so
Zend extensions using:zend_extension=some_extension.so
.
If you want to connect via the command line argument, then for ordinary ones:php -d extension=/path/extension.so
And for zend extensions:php -z /path/zend_extension.so
However, under the hood they are very different.
It is very suitable analogy with a gasoline and diesel engine. For the user, the only difference is in the type of fuel that he poured into the tank, but in fact these are two completely different designs, with different principles of operation and with their pros and cons.
Standard extensions, in the overwhelming number of cases, are used to extend the functionality of the language, such as adding new classes, functions, constants, etc. It is rarely used for other tasks. For example, the PECL extension Vulcan Logic Disassembler (vld) allows you to see the generated opcode for the script.
Zend extensions are used in cases when you need to get as deep as possible inside a virtual machine. For example, for debugging or profiling a script, or for changing the logic of PHP.
Writing normal extensions is well documented and described in a variety of articles. For them, there is even a project skeleton generation tool included in the PHP source code.
In the case of the Zend extension, this is nothing. Virtually no good articles. Bad too. Be prepared for a long and thoughtful study of the source codes of both PHP itself and the few existing extensions of this type.
Unfortunately, there is no way to do without the C code, since the life cycle of the expansion is entirely a reflection of its determining structure. ( Structures are given in abbreviated form. Only what is necessary in the framework of the article )
The standard extension is defined by the _zend_module_entry
structure (described in zend_module.h
)
struct _zend_module_entry { /* skipped */ int (*module_startup_func)(INIT_FUNC_ARGS); /* MINIT() */ int (*module_shutdown_func)(SHUTDOWN_FUNC_ARGS); /* MSHUTDOWN() */ int (*request_startup_func)(INIT_FUNC_ARGS); /* RINIT() */ int (*request_shutdown_func)(SHUTDOWN_FUNC_ARGS); /* RSHUTDOWN() */ void (*info_func)(ZEND_MODULE_INFO_FUNC_ARGS); /* PHPINFO() */ /* skipped */ void (*globals_ctor)(void *global); /* GINIT() */ void (*globals_dtor)(void *global); /* GSHUTDOWN */ int (*post_deactivate_func)(void); /* PRSHUTDOWN() */ /* skipped */ };
The Zend extension is defined by the _zend_extension
structure (described in zend_extensions.h
)
struct _zend_extension { /* skipped */ startup_func_t startup; /* STARTUP() */ shutdown_func_t shutdown; /* SHUTDOWN() */ activate_func_t activate; /* ACTIVATE() */ deactivate_func_t deactivate; /* DEACTIVATE() */ message_handler_func_t message_handler; /* MESSAGE_HANDLER() */ op_array_handler_func_t op_array_handler; /* . */ /* , , , * */ statement_handler_func_t statement_handler; /* */ fcall_begin_handler_func_t fcall_begin_handler; /* */ fcall_end_handler_func_t fcall_end_handler; /* */ op_array_ctor_func_t op_array_ctor; /* OPArray */ op_array_dtor_func_t op_array_dtor; /* OPArray */ int (*api_no_check)(int api_no); /* API_NO_CHECK() */ int (*build_id_check)(const char* build_id); /* BUILD_ID_CHECK() */ /* skipped */ };
But now you can show a picture with the life cycle.
Yes. There is such an opportunity.
Why it may be needed?
OPCache
.An example of writing a simple Zend extension
Extremely useful resource on PHP internals
PHP Sources
Source: https://habr.com/ru/post/358714/
All Articles