On Thursday 08:14 AM 8/21/2008, Dossy Shiobara wrote:
4) I see the simplest (best?) solution here being a configurable parameter that controls fastpath's cache key generation. As Jim points out, one can quickly test whether this would solve the problem at hand by temporarily #define'ing _WIN32 in the appropriate place.
I'm not sure if I've mentioned this on the list, but the initial case that prompted us to discover the bug would not have been helped by this change; the main difference is that it would have shortened the debugging efforts. And this change would also alter current behavior in a major way, by defeating the explicit goal of having hard-linked files served from the same cache entry. A fix that doesn't resolve the initial problem and which has undesirable side effects isn't worth pursuing.
The change I offered is the only one that corrects the problem in the original code and all the other examples I've mentioned, transparently and without any serious side effects. Simply put, fastpath as designed should not be caching items that have been modified within the current second, because mtime's granularity (in combination with inode reuse) doesn't allow it to distinguish them from other items in the cache. Based on what Jim's said here, I'm guessing he wasn't thinking much about the mtime granularity issue because he thought inodes would be more than enough to ensure uniqueness, but that's not always the case (in fact it's usually *not* the case, since the two most widely-used filesystems reuse inodes).
In thinking about this further, barring a complete rewrite I don't think the fastpath caching mechanism *can* be fixed completely--it can only be improved.
- John -- AOLserver - http://www.aolserver.com/ To Remove yourself from this list, simply send an email to <[EMAIL PROTECTED]> with the body of "SIGNOFF AOLSERVER" in the email message. You can leave the Subject: field of your email blank.
