Hi Dmitry,
This is a bit different topic to FFI discussion so creating a new thread.
You wrote this in the FFI extension discussion:
At the same time, we will develop a technology to preload and reuse PHP
files across requests.
And allow FFI there.
Have you been thinking about it in the FPM context? I'm asking as I have
been pondering with a related idea about some restructuring how things work
currently in the FPM. I will try to give a quick overview of the current
way how things work (for those who read this and are not familiar with it),
the problem that it is already causing and finally the idea that I have. :)
The thing is that at the moment there is just a master process that except
other things does the module init and spawns children. Each child is then
configured by the pool configuration which means that it can have a
different effective user id. It's simple and it works in most cases.
However there is an issue if it tries to access shared resources in other
pools running under different user which can happen due to the fact that
the initialization is done during MINIT by master (root user in such
case). One example is the opcache that tries to kill lockers as described
in https://bugs.php.net/bug.php?id=74709 . I think that it's also not ideal
to do MINIT as a root from security point of view (the last security issue
is actually good example of that - https://bugs.php.net/bug.php?id=75605 ).
However not sure if there are some extension that depends on it.
As you can imagine, it would get even worse if you allow preloading of PHP
script in master so such implementation would be a no-go IMHO.
What I have been thinking about is to have a new process (I will call it a
pool manager) for each pool that would except other things spawn and manage
children and run under the same user. It would also do the MINIT and it
could possibly preload PHP files and load the libraries for FFI
(considering there would be a support in the engine for that - some kind of
partial execution or whatever you think would be best). Master would then
spawn and manage the pool managers as well as doing other things like log
handling. That would prevent the user mix up mentioned above - in the
example case, the opcache would have separate shared memory for each pool.
WDYT?
Cheers
Jakub
Hi Jakub,
I though not only about FPM, but a technology for any SAPI.
Pre-loaded classes and functions might be kept in CG() tables, in the same way as "internal" ones.
EG() constants and variables may be re-created at start of request, executing pre-loaded PHP code.
Few years ago, I developed something similar for PHP-5.
Thanks. Dmitry.
Hi Dmitry
Hi Jakub,
I though not only about FPM, but a technology for any SAPI.
Pre-loaded classes and functions might be kept in CG() tables, in the same
way as "internal" ones.EG() constants and variables may be re-created at start of request,
executing pre-loaded PHP code.Few years ago, I developed something similar for PHP-5.
Yeah that's what I kind of meant by the engine support. :) My idea was more
about when it should be preloaded. For example one option would be to
preload it automatically if nothing has been preloaded as part of
php_execute_script / zend_execute_script. However that would mean to do it
for each child (basically use it for all request for the child process
life). It should work and might be a viable options for the initial
implementation but more optimal would be do it once for all children
running in the same pool which could be doable using the pool managers. I
think it would be great to have some kind of API so the SAPI can explicitly
preload the script.
Cheers
Jakub