On Wednesday 01:45 PM 8/20/2008, Juan José del Río wrote:
But, since Linux version 2.6.13, inotify is into the kernel, and
aolserver can subscribe to a path, so know if that file has been
deleted, modified, or anything else. That's the way a cache can know if
the file has been altered in any way, and it should be marked as dirty.
As easy as that... but I know it is harder than that one-line-patch.

inotify isn't available as of Redhat Enterprise Linux 4, and I'm sure there are other major distributions that are missing it as well--so while it may be the best approach eventually it won't solve the problem right now. Also, not all platforms use inotify, so adding filesystem monitoring support would require complex cross-platform code (which in some cases won't even be available). So while I'd agree with you that the eventual (ideal) solution is a major rewrite of the fastpath caching code to use some sort of filesystem monitoring technique, that won't work now.

By comparison, the fix I offered will work just fine on all the platforms that AOLserver runs on, right now, and it fixes all non-pathological use cases (i.e., all but ones that are artifically designed to trip it up). As to whether it's a hack, possibly, but so is the fastpath code--that's the whole problem. The patch corrects a specific flaw in the original code: that fastpath never should have been caching files that were modified within the last second, since the underlying OS mechanism (mtime) doesn't provide the resolution necessary to distinguish reliably between two such files. In other words, the patch is in the same spirit as the original code--so if you really don't want such ugliness in your code you should probably just strip out fastpath caching entirely. :-)

- 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.

Reply via email to