On Jan 14, 2020, at 1:10 PM, Larry Garfield <la...@garfieldtech.com> wrote:
>> I get your concern about recursion, but if that kind of issue is really
>> a concern I don't see why we could not artificially limit recursion on
>> preload to a configurable amount, with 100 being the default?
>
> It's not recursion itself that's an issue. It's that the behavior of the
> code changes between preload and non-preload contexts in subtle, non-obvious
> ways.
>
> I don't mean a recursive function that runs during preload. I mean if a
> function that runs in a normal request is written recursively, it will fail
> at high recursion levels only if the file it is in was not preloaded. So
> whether or not foo.php was run through opcache_compile_file() changes when
> and how code in that file will fail. That's the situation we want to avoid
> like the plague, IMO.
With respect, that feels like you are concerned about some real edge cases, and
ignoring the probability that most code run during preloading would be written
bespoke for preloading.
ALSO, I think I may have caused confusion by calling it "preloading." In my
mind that meant "run once" vs. "run for each page load" but I think you are
(rightly) conflating what I have called "preloading" with the new preloading
feature in PHP 7.4?
What I have been envisioning is a `preload` (or some other) keyword that we
could apply to functions, methods, and expressions. When `preload` modified
functions/methods/expressions are reached during OpCode generation, rather than
generate a call to runtime code PHP would just run the code and then take the
return value and generate OpCode for that return value.
class Foo {
preload function bar() {
return < a_really_time_consuming_expression>;
}
}
$foo = new Foo();
echo $foo->bar(); // This would not actually execute anything at runtime.
// It would simply echo the constant value that
was
// returned by
<a_really_time_consuming_expression>.
I could be wrong but I find it hard to believe the runtime profile would be so
different in this context as to create problems of the nature you are fearing.
Maybe someone like Dimitry who understand the OpCode generation process could
weigh in?
>> I do completely see your points about the AST and most PHP developers.
>>
>> The unfortunate problem with PHP is there is no way to use 3rd party
>> code to extend PHP w/o being able to reconfigure the server by adding
>> extensions. It would be nice if we could come up with a way for 3rd
>> party developers writing in C or another language — people who are more
>> likely to test their code before distributing it — to extend PHP such
>> as by generating OpCode files that a userland developer could load.
>
> That... sounds a lot like the new FFI extension? Write code in C or Rust or
> anything that can produce a .so file, plug it into PHP, go?
Unless I am misunderstanding, using an .so requires a sysadmin to add an
extension and update php.ini. Which is a non-starter on hosted sites like
Pantheon, WPEngine, Kinsta, Pagely, Flywheel, PressLabs and similar.
What I was instead calling for what a way to extend PHP that a userland
developer with no access to php.ini would be able to achieve.
Interestingly, after my above comment I googled and came across this PHP
extension that can load a compiled Web Assembly (.wasm) file. Something like
this in core would be very useful:
https://github.com/wasmerio/php-ext-wasm
-Mike
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
