On Jan 11, 2015 11:38 AM, "François Laupretre" <franc...@tekwire.net> wrote: > > > De : Pierre Joye [mailto:pierre....@gmail.com] > > > > > Sorry, I am not sure I understand how the opcode cache, as it exists now, > > can understand this. Do you mean that opcode cache code would need to be > > modified ? > > > > Yes and no. Yes if we want them to do not even try to update files > > that are statically built in extensions. And yes, if we want that (for > > whatever reasons I cannot think about right now). > > Sorry, it must be too late :) > > AFAIR, the opcode cache attempts a stat() call on the filename it receives to get its mtime and use it to determine if file was modified since it was cached. I don't understand how an opcode cache can do a stat() on the filename you provide as, without a stream wrapper, there is no way to access such information (which doesn't even have any sense here). Your filename will be recognized as a plain filename, the libc stat() call will look for this filename in the current directory, it won't be found, and opcode caching will fail. If the file doesn't have an associated stream-wrapped path, you cannot issue a stat() on it and I don't see how it can be cached. Where am I wrong ?
Say we do support builtin scripts, an opcache will simply load them on minit or on the first request and flag them as permanent. Yes, it means we need to change opcache but could be way easier than trying to hack the engine to support persistent Opcodes without ending with ... an opcache. > > That's PHP7, we can and have already broken BC internally. > > So, you confirm that opcache is the only supported opcode cache in PHP 7 ? That's a good thing. I know that PHP7 breaks BC, I just wanted to know if developments in this branch had to remain compatible with APC and friends. It is almost already the case for 5.5+, apc is dead for anything >= 5.5
