1. The comparison is:
   if(t - buf.st_mtime < 2)
   Are you suggesting changing this to != ?
   That doesn't make any sense.

2. We don't lock until we try to insert the new cache entry.
   That means we have to allocate a number of things before the lock.  By warming up new entries by hitting them once before making them live we avoid this rush of multiple processes all trying to allocate the memory needed to do an apc_cache_insert().  And by the way, the Smarty folks realized it was stupid to backdate things like that and they no longer do it so Smarty doesn't need this.

3. Yes, a filesize check makes sense.  I looked at adding this before.

1.
i'm lost

i see only:
            if ((*slot)->key.mtime < key.mtime) {
where is < 2 ?

2. by read the source, i know we don't lock until cache_insert, but how about adding 1 more lock?
in my previous example, there's already 2 locks: 1 my*lock(), 2 include(), the one by apc
lock(compile_lock) (different from cache lock)
recheck();
allocate()
complile()
optimize()
apc_cache_insert() (which also do lock/unlock)
unlock(compile_lock)

this, however, make only 1 file (and by 1 process) at a time.
but: 1. it's good for "after restart", or a "cache clear". also simpler than user do themself
2. user can do nothing with static php file, apc should take care of warming up.
3. win32 have no inode, only filename(if we implement it), rename()+hit is useless to warm up
although, win32 is only a devel-test for me

1. http://cvs.php.net/co.php/pecl/apc/apc_cache.c?r=3.74
Line 550

2. Locks are expensive.  The less of them the better.

3. I really don't care about win32 and I certainly don't want a win32 problem affecting non-win32 platforms.  #ifdef a different approach for win32.

And by the way, using the filename as a key is way too expensive.  I don't know the filename in my version of PHP, for example because I removed the expensive realpath() call so if you do include "./foo.php" in one directory and then do include "./foo.php" in another directory these two ./foo.php files are obviously different but without a realpath() call they look the same.  A stat to get the device+inode is much much quicker than calling realpath() on it.

oops, i didn't see the cvs before i post this bug
i never meant to hurt "if(t - buf.st_mtime < 2)"

1. the request for != is about "if ((*slot)->key.mtime < key.mtime) {".
my point is: some ftp may preserve mtime when uploading or downloading. well, maybe i (and other users) should configure the client not to do so. but i still don't know why we need < not !=

2. lock is expensive, but not each request need compile_lock. only when we're going to compile.
if (check_if_should_compile()) {
 lock(compile_lock);
 if (check_if_should_compile()) { // again
    ......
 }
 unlock(compile_lock);
}

your slam_defense way looks good for me. it won't make too much child locking together even without a nonblocking-lock

3. i never meant to remove inode checking, and yes, use #ifdef
(filename for win32) + (inode for most other system) is done by mmcache. apc can do it too.

I think you are right about

  if ((*slot)->key.mtime < key.mtime)

I can't think of a good reason for not making that a != check.
George, Dan, anybody else?

This bug has been fixed in CVS.

In case this was a documentation problem, the fix will show up at the
end of next Sunday (CET) on pecl.php.net.

In case this was a pecl.php.net website problem, the change will show
up on the website in short time.
 
Thank you for the report, and for helping us make PECL better.

This bug has been fixed in CVS.

In case this was a documentation problem, the fix will show up at the
end of next Sunday (CET) on pecl.php.net.

In case this was a pecl.php.net website problem, the change will show
up on the website in short time.
 
Thank you for the report, and for helping us make PECL better.