One other idea could be to modify the code so that the Win32 behavior
(cache by filename) could be made a configurable option (perhaps
default on) instead of compile-time. Would be easy to fiddle with
code snippets like this to make that happen:
#ifdef _WIN32
key = file;
#else
ukey.dev = stPtr->st_dev;
ukey.ino = stPtr->st_ino;
key = (char *) &ukey;
#endif
Note similar code is in ADP. The downside to filename-based cache is
the keys are bigger strings instead of small fixed sized structures
(tiny) and double caching for files which are actually the same via
symlinks (could be large or nothing if you're using symlinks). Both
cases result in more memory but perhaps safer results. One positive
is the ns_cache_keys, size, etc. commands would show results for
fastpath objects by filename (I think they ignore non-string based
cache keys now).
In fact, I suppose you could just add this to the top of fastpath.c
and recompile to try it out:
#define _WIN32 1 /* Get Win32 filename-based cache keys */
As long as your filenames are unique names, this may give you the
results you're looking for (although I still think a dynamic app using
files should use open/cached fd's).
-Jim
On Aug 19, 2008, at 9:25 PM, John Caruso wrote:
On Tuesday 05:39 PM 8/19/2008, Jim Davidson wrote:
Your right, the code snippet below could trip over a race condition
as you've described.
It's not a race condition, actually; the code in that example was
serialized, so there's no race involved.
...fastpath isn't broken.
It's designed in such a way that it can return incorrect results
(and ones that are wildly outside of reasonable expectations).
Whether or not that's broken is a judgment call, and there we
apparently differ, though I find that surprising--just because bad
behavior can be documented and avoided doesn't mean it's not bad
behavior.
Anyway, for your app, it might be easiest to not change your code but
instead write a new ns_returnfile to override the builtin -- maybe
just with open and ns_returnfp.
Yep, that was essentially my original suggestion to the developers.
I can guarantee you that all uses of ns_returnfile will be receiving
close scrutiny. :-)
On Tuesday 05:59 PM 8/19/2008, Juan José del Río wrote:
If you don't want to deactivate it, and have some C skills, I would
recommend you to make the needed changes to fastpath code to enable
it
to use the kernel facilities of the operating system (in case you're
using linux, then that'll be "epoll" system call; in FreeBSD case
it's
kqueue; etc.).
This is an interesting suggestion, but from a quick scan of the
epoll man page it doesn't look like it would work in this case since
it acts on an open file descriptor, but fastpath associates file
data with a (dev, inode, mtime, size) tuple without keeping an open
file descriptor (and it'd be pretty wonky for AOLserver to keep open
file descriptors for all files currently in the fastpath cache).
No matter, though, we've got plenty of workarounds, and we'll
probably just disable fastpath entirely since the benefits are
likely vanishingly small anyway.
- 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.
--
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.
