Пишем расширение для PHP

Пишем расширения для PHP Часть I: Введение в PHP и Zend

Пятница, Январь 14th, 2011 | Программирование

(5 голосов, средний: 5.00 из 5)

Loading ...

Это моя первая переводная статья Начать я решил именно с перевода серии англоязычных статей посвященных написанию расширения для PHP на С, потому что именно этим в данный момент я и занимаюсь, а так как информации в рунете об этом практически нет, я думаю, мой труд кому-нибудь обязательно пригодиться.

Ссылка на оригинальную статью.

Введение

Если Вы читаете это, то скорее всего Вам по какой-либо причине надо реализовать свое собственное расширение (extension) для PHP или Вам это просто интересно.

Данное руководство предполагает, что вы знакомы с двумя языками: PHP и С (на нем написан интерпретатор для PHP).

Начнем с того, что попытаемся представить для чего может понадобиться написать собственное расширение для PHP:

Есть какая-то библиотека или системная функция, которую Вам необходимо использовать/вызвать, но из-за «высокой» степени абстракции PHP Вы этого сделать просто не в состоянии.
Вы хотите заставить PHP вести себя каким-то необычным образом.
У Вас уже есть какой-то написанный PHP код, но вы знаете, что он мог бы работать быстрее и требовать меньше памяти, если его переписать как расширение PHP на C.
У Вас есть какой-то код на PHP, который вы хотите продать, и при этом не хотите отдавать исходники.

Для того чтобы создать свое расширение PHP, для начала, необходимо понять, что такое расширение для PHP.

Что такое расширение для PHP?

Если вы использовали раньше PHP, то вы, почти со 100% вероятностью, пользовались расширениями. Лишь небольшое количество функции в PHP реализовано не в расширениях. Большинство функций – часть стандартного расширения – их около 400. PHP в базовой комплектации поставляется с 86 расширениями, каждое из которых, в среднем, содержит около 30 функций (около 2500 функций). Если этого недостаточно, то репозиторий PECL предлагает еще около 100 дополнительных расширений, не говоря уже о том, что их можно просто найти Интернете.

Ядро PHP сделано в виде двух отделенных друг от друга частей.

На нижнем уровне – the Zend Engine (ZE). ZE парсит PHP скрипт в последовательность понимаемых машиной токенов, а затем исполняет эти токены в текущем процессе. Также в ZE есть менеджер памяти (он занимается выделением/высвобождением памяти), пространство переменных (контекст), и обработчик вызовов функций.

Другая часть – ядро PHP. PHP осуществляет взаимодействие и реализует связи со слоем SAPI (Server Application Programming Interface, чаще всего употребляется для указания сервера, на котором выполняются скрипты – Apache, IIS, CLI, CGI, и т.д). Также ядро реализует унифицирующую прослойку для контроля safe_mode и open_basedir, операций с потоками (файлы + сеть), т.к. они используют единые функции чтения ( fread() ), записи( fwrite() ), открытия потока ( fopen() ).

Жизненный цикл скрипта

Когда SAPI запускается, например, в ответ на команду /usr/local/apache/bin/apachectl start, PHP начинает инициализировать подсистемы ядра. Перед окончанием начальной(стартовая) инициализации, ядро загружает расширения, вызывая при этом функцию инициализации расширения Module Initialization (MINIT). Это дает возможность каждому из них провести инициализацию: внутренних переменных, занять требуемые ресурсы, зарегистрировать хэндлы (handlers) ресурсов, зарегистрировать собственные функции в ZE, чтобы при вызове какой-либо функции расширения в скрипте ZE знал какой код необходимо выполнить.

Далее, PHP ожидает пока SAPI примет и обработает запрос от браузера на получение страницы. В случае если PHP запускается как CGI или CLI SAPI, то это происходит мгновенно и только один раз. В случае если речь идет о Apache, IIS или другом полноценном веб-сервере SAPI, то это происходит тогда, когда пользователи запрашивают страницы. К тому же, запросы повторяется любое количество раз, и, разумеется, могут приходить одновременно. Не важно каким образом пришел запрос, PHP запрашивает ZE, чтобы тот в свою очередь настроил окружение, в котором будет запущен скрипт, вызвал у каждого из расширений функцию инициализации Request Initialization (RINIT) (здесь идет речь не о стартовой инициализации, а о той, что выполняется при каждом запросе пришедшем от браузера к серверу, который, в свою очередь, обработал и перенаправил его к нам в скрипт).

Вызов функции RINIT дает возможность расширению настроить значения каких-то переменных окружения, занять какие-то специфические ресурсы, или выполнить другие задачи, например, аудит. Ярким примером, того что можно включить в функцию инициализации RINIT – небольшая автоматизация усилий, если флаг session.auto_start поднят, то RINIT автоматически вызывает функцию session_start() и предварительно заполняет переменную $_SESSION.

Как только функции RINIT всех подключенных в данный момент расширений будут выполнены, ZE переводит PHP код в токены, а затем в коды операций (opcodes), по которым он cможет пройти и выполнить их. Если одной из этих операций потребуется вызвать функцию расширения, то ZE упакует переданные аргументы для данной функции и передаст ей управление до тех пор пока она не завершится.

После того как выполнение скрипта будет завершено, PHP вызовет для каждого загруженного расширения функцию очистки Request Shutdown (RSHUTDOWN) (здесь, например, может выполняться сохранение сессионных переменных на диск). Затем, ZE запустит сборщик мусора, который вызовет для каждой переменной использованной в предыдущем запросе функцию unset().

Как только сборщик мусора сделает свое грязное дело, PHP перейдет в режим ожидания следующего запроса от SAPI на обработку скрипта веб-страницы, или сигнала отключения. В случае CGI или CLI SAPI, не существует «следующего запроса», поэтому SAPI инициирует отключение незамедлительно. В течении отключения, PHP снова проходит по списку загруженных расширений и вызывает для каждого из них функцию деинициализации Module Shutdown (MSHUTDOWN). И, наконец, PHP выгружает подсистемы ядра.

Этот процесс может показаться Вам, на первый взгляд, сложным, но как только Вы погрузитесь в разработку расширений, все для Вас постепенно прояснится.

Операции с памятью

Для того чтобы избежать утечек памяти в плохо написанных расширениях, ZE реализует свой собственный менеджер памяти, используя при этом дополнительный флаг, необходимый для определения времени жизни отведенного участка памяти. Суть этого флага в том, чтобы эффективно и корректно удалять отведенную вашим расширением память, а если быть точным, то менеджер памяти должен знать когда «подчистить за вами мусор» (если вы этого сами не сделали) после выполнения генерации страницы или в момент завершения SAPI и деинициализации расширений.

Перманентное отведение памяти означает, что память будет высвобождена при деинициализации PHP перед завершением работы SAPI. Напротив, не перманентно отведенная память (не путать с обычными функциями отведения памяти в C) будет освобождена в конце запроса, в котором она была отведена, в независимости от того была ли вызвана функция высвобождения памяти или нет (если нет, то за вас это сделает сборщик мусора, являющийся частью менеджера памяти ZE). Под пользовательские переменные, определенные в скрипте, память отводятся не перманентно, так как их значения к концу запроса становятся бесполезными, то память отведенная под них будет высвобождена сборщиком сборщиком мусора по окончании обработки данного запроса.

Расширения могут «положиться» на то, что ZE сам высвободит не перманентную память, которую они отвели в рамках запроса, но это не рекомендуется. Врядли участки памяти не востребованные в течении «длительных» периодов времени и ресурсы ассоциированные с этой памятью будут высвобождены корректно, поэтому рекомендуется «прибираться за собой» высвобождать отведенную в пределах запроса память. Как вы поймете позднее, достаточно легко убедиться в том, что вся отведенная память была высвобождена корректно.

Давайте сравним традиционные функции отведения памяти (эти функции должны быть использованы только при взаимодействии с внешними библиотеками) с функциями отведения постоянной (перманентной) и не постоянной памяти.

Традиционные	Не постоянные	Постоянные
`malloc(count)` `calloc(count, num)`	`emalloc(count)` `ecalloc(count, num)`	`pemalloc(count, 1)`^* `pecalloc(count, num, 1)`
`strdup(str)` `strndup(str, len)`	`estrdup(str)` `estrndup(str, len)`	`pestrdup(str, 1)` `pemalloc() & memcpy()`
`free(ptr)`	`efree(ptr)`	`pefree(ptr, 1)`
`realloc(ptr, newsize)`	`erealloc(ptr, newsize)`	`perealloc(ptr, newsize, 1)`
`malloc(count * num + extr)`^**	`safe_emalloc(count, num, extr)`	`safe_pemalloc(count, num, extr)`

* Семейство функций pemalloc() включает флаг «постоянства», который позволяет им вести себя как их «не постоянные коллеги».

Например, emalloc(1234) это тоже самое что и pemalloc(1234, 0).

**safe_emalloc() и (в PHP 5) safe_pemalloc() осуществляют дополнительную проверку, чтобы избежать переполнения integer’а.

Подготавливаем среду для разработки

Теперь, когда мы рассмотрели немного теории о том как работает PHP и Zend Engine, я могу поспорить, что Вам уже хочется начать что-то писать. Но перед тем как вы что-либо будете делать, вам необходимо собрать определенный набор инструментов для разработки и настроить окружение сообразно вашим целям.

Первое, что вам понадобиться – сам PHP, и набор инструментов необходимых, чтобы его скомпилировать. Если вам никогда не доводилось собирать PHP из исходников, то я вам предлагаю взглянуть на http://www.php.net/install.unix (Разработка расширений PHP под Windows будет рассмотрена в одно из следующих статей). «Почему бы не использовать установленный скомпилированный PHP?» – спросите вы, дело в том, что при его построении небыли переданы два очень важных для процесса разработки ./configure ключа.

Первый –enable-debug, эта опция соберет PHP с дополнительной символической информацией, таким образом в случае возникновения ошибки segmentation fault, вы сможете получить дамп и воспользоваться gdb, чтобы определить где и почему произошла ошибка.

Следующая ./configure опция различается для разных версий PHP. В PHP 4.3 эта опция называется –enable-experimental-zts, в PHP 5 и более поздних это --enable-maintainer-zts. Эта опция заставит PHP думать, что он запущен в много поточной среде и Вы сможете отловить ошибки, которые были безвредны в одно поточном режиме, но сделали ваше расширение непригодным в многозадачной среде.

После того как вы скомпилировали PHP используя эти дополнительные опции и установили его на свой компьютер, вы можете начинать писать свое первое расширение для PHP.

«Hello world»

Как же можно обойтись без пресловутого Hello World?! В нашем случае мы сделаем небольшое расширение с единственной экспортируемой функцией, которая возвращает строку «hello world». Вот как это бы выглядело в PHP:

Исходный код на PHP

<?php
 
function hello_world() {
    return 'Hello World';
}
 
?>

А теперь давайте превратим это в расширение для PHP. Во-первых, создайте папку с именем hello в директории ext исходников PHP и перейдите в нее. На самом деле эта папка может располагаться где угодно – как в дереве каталогов исходников PHP, так и вне его, однако я хочу чтобы вы поместили его именно туда, т.к. это немного упростит нам жизнь . Здесь вам необходимо создать 3 файла:

Собственно исходник (hello.c) с реализацией функции hello_world;
Заголовочный файл (php_hello.h), содержащий необходимые PHP ссылки для того чтобы он смог загрузить его как расширение;
Конфигурационный файл (config.m4) для phpize, которое займется подготовкой вашего расширения к компиляции.

Итак, содержимое вышеописанных файлов:

Исходный код config.m4

PHP_ARG_ENABLE(hello, whether to enable Hello World support,
[ --enable-hello   Enable Hello World support])
 
if test "$PHP_HELLO" = "yes"; then
  AC_DEFINE(HAVE_HELLO, 1, [Whether you have Hello World])
  PHP_NEW_EXTENSION(hello, hello.c, $ext_shared)
fi

Исходный код на C (php_hello.h)

#ifndef PHP_HELLO_H
#define PHP_HELLO_H 1
 
#define PHP_HELLO_WORLD_VERSION "1.0"
#define PHP_HELLO_WORLD_EXTNAME "hello"
 
PHP_FUNCTION(hello_world);
 
extern zend_module_entry hello_module_entry;
#define phpext_hello_ptr &hello_module_entry
 
#endif

Исходный код на C (hello.c)

#ifdef HAVE_CONFIG_H
#include "config.h"
#endif
 
#include "php.h"
#include "php_hello.h"
 
static function_entry hello_functions[] = {
    PHP_FE(hello_world, NULL)
    {NULL, NULL, NULL}
};
 
zend_module_entry hello_module_entry = {
#if ZEND_MODULE_API_NO >= 20010901
    STANDARD_MODULE_HEADER,
#endif
    PHP_HELLO_WORLD_EXTNAME,
    hello_functions,
    NULL,
    NULL,
    NULL,
    NULL,
    NULL,
#if ZEND_MODULE_API_NO >= 20010901
    PHP_HELLO_WORLD_VERSION,
#endif
    STANDARD_MODULE_PROPERTIES
};
 
#ifdef COMPILE_DL_HELLO
ZEND_GET_MODULE(hello)
#endif
 
PHP_FUNCTION(hello_world)
{
    RETURN_STRING("Hello World", 1);
}

Как вы видите, большая часть кода – это настройка своеобразного протокола, который PHP использует для взаимодействия с собственными расширениями. И только последние четыре строчки – та самая функция hello_world, представленная в слегка непривычном виде (из-за использованных макросов PHP_FUNCTION и RETURN_STRING). Эти макросы призваны упростить написание расширений для PHP, поэтому их не стоит бояться к ним надо просто привыкнуть( в последствии вы ими будете пользоваться очень часто).

В принципе, из названия макросов следует их предназначение (я бы даже сказал, что они максимально пытаются приблизить нас к PHP реализации функции hello_world), однако, я думаю вас мучает вопрос «Что значит последний параметр макроса RETURN_STRING и почему он равен единице?«.

Напомним, что ZE включает в себя сложный механизм управления памятью, который следит за тем, чтобы вся выделенная память была освобождена сразу после того как скрипт завершит свое выполнение. Самой большой проблемой при использовании менеджеров памяти является двойное освобождение одного и того же участка памяти. Это наиболее частая причина появление «segmentation faults» в Linux.

Аналогично, я не думаю, что вы хотите чтобы ZE освободил статический буфер, в котором содержится строка «Hello world», сразу после того как выполнение данной функции завершиться, а переданный указатель на строку окажется недействительным, из-за того что он указывает на область памяти не принадлежащую ни одному из процессов. Поэтому, макрос RETURN_STRING может произвести копирование переданной ему строки, чтобы впоследствии корректно высвободить память, в которой находилась копия строки. Именно это и означает последний параметр макроса RETURN_STRING :

1 – копировать строку;
0 – не копировать строку, а вернуть указатель.

Но так как не принято, чтобы внутренние функций отводили память для строки, заполняли ее содержимым, а потом возвращали ее, поэтому и был создан макрос RETURN_STRING, который позволяет сделать или не сделать копию возвращаемой строки.

В следующем примере приведены действия идентичные вызову макроса RETURN_STRING с параметрами («Hello World», 1):

Текущее значение	Оригинальное значение	Тип
INI_STR(name)	INI_ORIG_STR(name)	char *
INI_INT(name)	INI_ORIG_INT(name)	long
INI_FLT(name)	INI_ORIG_FLT(name)	double
INI_BOOL(name)	INI_ORIG_BOOL(name)	zend_bool

Жизнь кодера

голова программиста – взгляд внутрь

Пишем расширения для PHP Часть I: Введение в PHP и Zend

Пятница, Январь 14th, 2011 | Программирование

(5 голосов, средний: 5.00 из 5) Loading ...

Оставить отзыв

Свежие записи

Наиболее интересные

Рубрики

Архивы

Поиск по блогу

(5 голосов, средний: 5.00 из 5)

Loading ...