FFI и Opcode cache

[Yoskaldyr]

Вопрос из разряда извращений.
Возможно ли как-то используя FFI заставить opcache кешировать stream wrapper-ы отличные от file и phar?
Моих знаний внутренностей пхп и си недостаточно для этого

 

[fixxxer]

Я фиг его знает насчёт FFI, но вот был такой rfc: https://wiki.php.net/rfc/url-opcode-cache

New 'cache_key' streams operation by flaupretre · Pull Request #1711 · php/php-src

This PR is not ready for merge yet. Vote for the corresponding RFC is open. This is a follow-up to #976. The 'cache_key' operation allows opcode caches to ask stream wrappers whether a give...

github.com

 

[Yoskaldyr]

так этот рфс был фиг знает когда и все по нему заглохло практически сразу
потому и спрашиваю насчет ffi, может есть знатоки си и внутренностей пхп.

 

[WMix]

а ты хочешь ffi на fpm использовать? может задачи просто стоит разделить?

 

[Yoskaldyr]

@WMix именно. Если более точно, то нужно кеширование для автогенерированного кода когда фс только для чтения. Поэтому нужно кешировать пользовательские stream wrapper-ы.
Я понимаю что скорее всего это не решаемая задача, но думал вдруг есть кто знает внутренности и можно как-то принудительно заставить или обмануть пхп через ffi.

 

[WMix]

в линухе все файлы, если уж, то наверняка можно попайпить, копай.. а что за сервис заюзать хочешь если не секркт?

 

[Yoskaldyr]

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

 

[c0dex]

В плане какой безопасности?

Сделай рамдиск, пиши в него что хочешь.

 

[Yoskaldyr]

В плане какой безопасности?

Сделай рамдиск, пиши в него что хочешь.

Проехали. Я более чем сам прекрасно понимаю что задача полная дичь (вернее не сама задача а ее причины). Клиенты разные и админы у них бывают разные и у некоторых есть мания ставить RO на все файлы - типа безопасно. Не надо писать что это бред - я сам это прекрасно понимаю.
Было просто интересно обойти ограничение опкод кеша, потому что моих знаний внутренностей пхп и си недостаточно. Изначально же написал извращение. Как сейчас сделано даже не буду писать ибо еще большее извращение, но таков он фриланс бессмысленный и беспощадный.

Все-таки темы сталкера не сильно хорошо влияют и на отвечающих, теперь любой вопрос все пытаются что-то додумать чего нет, а не просто ответить напрямую.

 

[WMix]

зря ты так, наоборот, понять хочется, в каждом изврате есть зерно истины.

у некоторых есть мания ставить RO на все файлы - типа безопасно

чем строже тем лучше, осталось исключений добавить

 

[MiksIr]

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

Нормальное вполне желание, что бы код был RO в продакшене. Проблема "кодогенерации" решается прогревом этого кеша до деплоя.

 

[fixxxer]

@WMix именно. Если более точно, то нужно кеширование для автогенерированного кода когда фс только для чтения. Поэтому нужно кешировать пользовательские stream wrapper-ы.
Я понимаю что скорее всего это не решаемая задача, но думал вдруг есть кто знает внутренности и можно как-то принудительно заставить или обмануть пхп через ffi.

Я посмотрел.
Там со времен того rfc ничего не поменялось, в opcache адовый хардкод кейсов с file:// и phar:// (для него специальные костыли), это не обойдешь никак, кроме как патчить opcache.
С точки архитектуры это вообще полная жесть (и в rfc товарищ правильно предлагал вместо хардкода в opcache перенести ответственность за управление кэшированием в соответствущие ext-ы), но, наверное, с точки зрения производительности такое оправдано.

Еще интересно, что будет, если собрать php без phar и зарегистрировать кастомный phar stream wrapper. Судя по всему, всё навернется с грохотом. С другой стороны, если при этом укладываться в phar-схему, чтобы там парсер в opcache думал, что это настоящий phar, может, это и будет костыльным решением твоей задачи?

 

[Yoskaldyr]

Еще интересно, что будет, если собрать php без phar и зарегистрировать кастомный phar stream wrapper. Судя по всему, всё навернется с грохотом. С другой стороны, если при этом укладываться в phar-схему, чтобы там парсер в opcache думал, что это настоящий phar, может, это и будет костыльным решением твоей задачи?

вот это костыль! не подумал о нем ))) Как будет свободное время попробую такое извра
Буду иметь ввиду. пусть пока что остается текущий костыль через eval

 

[Yoskaldyr]

Нормальное вполне желание, что бы код был RO в продакшене. Проблема "кодогенерации" решается прогревом этого кеша до деплоя.

Это не нормальное желание когда система изначально проектировалась что у нее должны быть некоторые папки с доступом на запись. И это нельзя решить прогревом после деплоя, потому что код генерится от любого чиха в админке

 

[MiksIr]

Это не нормальное желание когда система изначально проектировалась что у нее должны быть некоторые папки с доступом на запись. И это нельзя решить прогревом после деплоя, потому что код генерится от любого чиха в админке

Прям битрикс какой-то

 

[Yoskaldyr]

Прям битрикс какой-то

обычное дело для коробочных решений.

 

[grigori]

как связаны ffi и stream wrappers?

 

[Yoskaldyr]

как связаны ffi и stream wrappers?

Например те же полноценные readonly properties можно было сделать через ffi еще до всех новых rfc. По аналогии подумал что может можно обойти и другое встроенное ограничение. Повторюсь знаний внутренностей пхп у меня не много.

 

[grigori]

а как сделать readonly на ffi?
что, вообще, такое кеширование stream wrapper-ов? stream wrapper - это ж просто класс

 

[fixxxer]

а как сделать readonly на ffi?

Ты ж сам как-то тут z-engine пиарил. Не уверен, что readonly можно (внутри пхп таких ручек и нет, если только какой костыль хитрый), но логика понятна, влезть во внутренности php через ffi.
Понятно, что можно влезть в zval или подергать внутренние апи, а не код opcache отреврайтить