On 23/11/2018 23:49, Zeev Suraski wrote:
I'm not sure if you're missing anything fundamental - it's just that the preload.php file Dmitry's referring to (the one that's responsible to loading all the other files) - is one file that's pretty much by definition, will be of no use at any later point in the lifetime of the server. It preloads other files (which of course, should very much persist in the opcache memory) - but once it's done, it's done. That's why it kind of makes sense not to cache it.
Ah, OK, so it's more a case of "don't bother caching" rather than "must avoid caching" then?
I think making it automatically uncached might be a bit confusing, and a source of future "gotchas". While it's *logical* for the INI setting to reference a stub file with nothing but includes, the feature as described in the RFC doesn't actually *require* this; it would be perfectly possible for someone to put a bunch of definitions in "preloaded_functions.php" and reference that one file directly in the preload directive. On the flip side, it's likely that frameworks will start shipping with their own preload helpers, so that you'd have "preload_all.php" reference "symfony/preload.php", and want to exclude *both* from the cache.
Thinking about it, I'm not clear exactly what a "do not cache" directive would mean in a preloaded file, since preloading is more than just caching. For instance, if "class A" is declared in a preloaded file with declare(cache=0), then "class B extends A" is declared in a preloaded file with caching enabled, how will class B be treated? Will the file containing class B be cached, but need to be referenced in an "include" statement in each request? Again, people will *probably* be using file structures and autoloaders that make this trivial, but the language doesn't require that.
Regards, -- Rowan Collins [IMSoP] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
