Как писать расширения под PHP7?

google://php7 extension если что, ообще не думаю что архитектурно что-то ищменилось со времен пых1

А вы понимаете, что добавляя тег «c» к тегу «php7» вы на самом деле не увеличиваете количество полезных посетителей темы (вам нужны php-шники, которые вдобавок что-то слышали про си-расширения), но зато увеличиваете количество остальных (теперь сюда попали ещё и те, кто интересуются чистыми сями, а php им до лампочки)?

о зато увеличиваете количество остальных (теперь сюда попали ещё и те, кто интересуются чистыми сями, а php им до лампочки)?

Подтверждаю, пых до лампочки.

А то везде какая-то древность из района 2005-го года и времён Zend Engine 1.

Может быть потому, что уже есть не достающий функционал в самом PHP? Может если опишите что хочется в mycoolextension.so пихануть, Вам быстрее ответят

https://secure.php.net/manual/en/internals2.structure.php

Конечно я там был. Ответа на интересующие вопросы не нашёл. Хотелось бы что-нибудь типа такого https://devzone.zend.com/303/extension-writing-part-i-introduction-to-php-and...

Нет такого функционала в самом PHP. Мне нужна функция jenkins_hash из модуля jenkins.so. Но в PHP7 модуль не работает, потому что zend_parse_parameters() возращает некорректный указатель на передаваемую строку. Я так понимаю, что это потому, что код моудля не менялся с 2007-го года, и что-то в его объявлении устарело. Вот мне и надо понять, как правильно надо писать, чтобы переписать модуль под современные реалии.

И да, не спрашивайте, почему именно jenkish_hash, а не любой другой. Я не знаю ответа на этот вопрос.

Ну а вдруг тут есть сишники, которым начальство сказало сваять что-то там на php, потому что так надо. Но сишник не поддался соблазну, написал модуль на С и доволен, т.к. внешне код на пыхе, а на самом деле на С.

https://wiki.php.net/internals/references

https://www.kchodorow.com/blog/2011/08/11/php-extensions-made-eldrich-install...
https://www.youtube.com/watch?v=5FoHyfu8meM
http://codingsteps.com/creating-php-extensions-in-c-on-linux/
http://www.sklar.com/software/php/2015/03/23/converting-a-php-extension-to-ph...
http://ahungry.com/blog/2016-09-29-Creating-a-php-7-extension.html

Вот за эту ссылочку http://www.sklar.com/software/php/2015/03/23/converting-a-php-extension-to-ph... большое спасибо. Секрет оказался вот в этом

Instead of receiving a string argument with s in the zend_parse_parameters() argument specifier string, I use S.

Но если посмотреть исходники модулей, которые идут с самим PHP, то там куча мест, где используется по старому через «s» и две переменных. Там работает, а тут не работало. Какая-то непонятная мне магия, но работает.

Не зря тэг C поставил.

флаги совместимости провтыквл? там же половина движка на дефайнах кажис. давно код смотрел очень.

Если что не так, то попробуй https://zephir-lang.com/

Бери уже реализованные расширения, смотри как сделаны.

Чтобы не создавать новый топик спрошу здесь.

KRoN73, как в php 7.0/7.1 обстоят дела с работой php-fpm?

Насколько его целесообразно юзать для «семерки» на слабеньких vps?

как в php 7.0/7.1 обстоят дела с работой php-fpm?

Да также, как и в php-5. Только, в среднем, вдвое быстрее и жрёт памяти вдвое меньше.

Насколько его целесообразно юзать для «семерки» на слабеньких vps?

Так альтернативы fpm всё равно нет :) (-cgi — сон разума, -apache жрёт больше). И php7-fpm намного актуальнее на VPS, чем php5-fpm, т.к. жрёт намного меньше ресурсов.

А fcgi чем не нравится, если не секрет?

А fcgi чем не нравится, если не секрет?

Требует лишнюю сущность, fcgi-менеджер. По сути fpm и есть же fcgi с предустановленным менеджером.

Так php-cgi в режиме fastcgi работает безо всяких лишних менеджеров — его роль на себя берет первый из PHP_FCGI_CHILDREN процессов.

Потому что расширения PHP пишутся на С

Какое отношение -cgi имеет к fast-cgi? Это разные технологии. У -cgi происходит запуск скрипта системой при каждом обращении. -fcgi — держит демона, отвечающего на запросы.

Ну как бы php-cgi сто лет в обед поддерживает FastCGI.

-b <address:port>|<port> Bind Path for external FASTCGI Server mode

Где-то на сайте php есть дока с описанием изменений в API для php7. Только там явно php7 не упоминается, а под другим девелоперским названием, типа Zend Next или что-то в таком роде

https://wiki.php.net/phpng-upgrading

ага, оно

1. Ну так это _уже_ fastcgi :)

2. А кто будет запускать нужное количество серверов, распределять по ним нагрузку, следить, чтобы не падали?

1

Ну так я и спрашивал, есть ли какие причины не использовать именно fcgi

Я последний раз смотрел fpm очень давно, еще в те времена, когда у него были конфиги на xml. Киллер-фичей лично для меня в то время было бескостыльное исполнение php под разными uid/gid. Но потом на сервере с 200+ пользователей все эти пулы процессов под каждого пользователя стали есть очень много памяти (динамического менеджера процессов тогда, ЕМНИП, еще не было). Я тогда подумал, что в принципе ничего не мешает реализовать смену uid/gid и опциональный chroot непосредственно перед выполнением запроса, написал соответствующее расширение Zend и отказался от fpm в пользу fcgi. В качестве приятного дополнения объем памяти, потребляемый php, стал более предсказуемым.

Но с тех пор я не смотрел в сторону fpm, поэтому мне интересно, какие сейчас есть у него преимущества в сценарии с большим количеством пользователей.

2. А кто будет запускать нужное количество серверов, распределять по ним нагрузку, следить, чтобы не падали?

Тот самый первый процесс из PHP_FCGI_CHILDREN :-) Если один из детей завершается (сам — например, после выполнения PHP_FCGI_MAX_REQUESTS запросов — или по ошибке), он его перезапускает автоматом.

  469 ?        Ss     0:03 /usr/bin/php-cgi -q -b /run/shm/php-fcgi.sock -c /etc/php/7.0/cgi/php.ini
18262 ?        S      0:54  \_ /usr/bin/php-cgi -q -b /run/shm/php-fcgi.sock -c /etc/php/7.0/cgi/php.ini
20245 ?        S      0:50  \_ /usr/bin/php-cgi -q -b /run/shm/php-fcgi.sock -c /etc/php/7.0/cgi/php.ini
22387 ?        S      0:48  \_ /usr/bin/php-cgi -q -b /run/shm/php-fcgi.sock -c /etc/php/7.0/cgi/php.ini
22389 ?        S      0:47  \_ /usr/bin/php-cgi -q -b /run/shm/php-fcgi.sock -c /etc/php/7.0/cgi/php.ini

Ну так я и спрашивал, есть ли какие причины не использовать именно fcgi

Ну так я и ответил — отсутствие встроенного менеджера :)

Тот самый первый процесс

А его кто будет запускать? Кто будет создавать пулы в нужном количестве и с нужными параметрами?

он его перезапускает автоматом

И кто будет рулить динамикой нагрузки?

А его кто будет запускать? Кто будет создавать пулы в нужном количестве и с нужными параметрами?

А кто php-fpm запускает? init-скрипт или юнит systemd. Запущенный php-cgi берет на себя роль менеджера и управляет дочерними процессами. Задать настройки, специфические для сайтов, можно через php.ini (настройки per-host и per-directory доступны с php 5.3 + поддерживается .user.ini)

И кто будет рулить динамикой нагрузки?

В каком плане? Порождать дополнительные процессы? Этого нет — php-cgi эквивалентен здесь php-fpm с pm=static.

А кто php-fpm запускает? init-скрипт или юнит systemd

Просто init-скрипты соответствующие идут сразу с php-fpm. Так что кроме инсталляции ничего делать не нужно. А вот php-cgi нужно пускать вручную или ставить отдельно spawn-fcgi

В каком плане? Порождать дополнительные процессы? Этого нет — php-cgi эквивалентен здесь php-fpm с pm=static

Вот, видишь.

Собственно, фишка в том, что fpm — это тот же самый fast-cgi (собственно, как у нас fpm расшифровывается?) но с допиленными мелочами. Поэтому fpm ничуть не хуже, fcgi, но и немножечко шьёт^W лучше :)