> De : Rasmus Lerdorf [mailto:ras...@lerdorf.com] > > Don't we already have this problem with chrooted FPM? I haven't tested it > more recently, but last time I tried, opcache would fail to invalidate the > cache > after updating the file. Worked fine with a non-chroot environment. Not > sure if this is related to the issues you mean here... > > Yes, like I said, this is an issue we have to address still. It is on > the TODO list and definitely looking for volunteers. I just wanted to > make sure that Francois' RFC didn't introduce something which would make > it harder to eventually fix this by not allowing for a non-path cache key.
Well, from what I see in accel_make_persistent_key_ex(), the key is the path or a concatenation of the path, the cwd, the include path... Of course, the idea is to avoid the stat() call. But I don't see how we can determine a reliable cache key without a stat(). Maybe opcache shouldn't compute the key by itself. For each file it receives, it would ask the corresponding wrapper for a cache key (and the plain files wrapper would do a stat() and return dev/inode/mtime). François -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
