Re: Interesting APC behaviour

If I'm not wrong, this only breaks APC when include_once_override is turned on. My vote is to drop the apc.include_once_override and make APC a bit simpler & neater. I've found that it behaves rather inconsistently when people start returning values from scripts. <?php function f($a = array(1)) { return $a; } return f(); has been a suspect case for some segvs. Cheers, Gopal On Sun, Oct 28, 2012 at 12:02 PM, Rasmus Lerdorf <rasmus@lerdorf.com> wrote: > On 10/27/2012 03:50 PM, Stas Malyshev wrote: >> Hi! >> >>> An APC-level fix might be to fix the include_once/require_once override >>> implementation to go to the cache first to see if the inode is there and >>> pull out the cached realpath and use that to check against the >>> included_files list. The downside is that we will likely end up with 2 >>> cache lookups on every include_once. >> >> Comparing inodes sounds like a good idea for APC. Or, rather, comparing >> device,inode tuples. However, it should be able to fall back to >> comparing paths for files that have no inode. >> >> However, this may lead to BC break in (admittedly very unlikely) >> scenario of file hardlinked under two different names. >> > > Ok, I have a working implementation which uses the normal APC cache > lookup mechanism which by default will use an inode lookup, so through > that we get the device+inode check, and it will then pull the realpath > instead of going through VCWD_REALPATH() to get a possibly incorrect > one. See the attached patch. This takes care of the hardlink scenario as > well because it checks both the inode and the cached path. Anyone see > any holes in this approach? > > -Rasmus