Date: Sun, 3 Aug 1997 14:21:47 -0700 (MST) From: Terry Lambert <terry@lambert.org> To: jkh@time.cdrom.com (Jordan K. Hubbard) Cc: fbsdlist@federation.addy.com, edmond@shaman.lycaeum.org, hackers@FreeBSD.ORG Subject: Re: Too many open files in System! Message-ID: <199708032121.OAA02311@phaeton.artisoft.com> In-Reply-To: <3101.870636403@time.cdrom.com> from "Jordan K. Hubbard" at Aug 3, 97 12:26:43 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> You simply need to implement file swapping. Keep a cache of file > descriptors you've opened and implement a simple LRU algorithm to > close those which haven't been used for awhile - in your code which > handles the failure cases for reads/writes, you then add an extra bit > of glue to handle the failure case (e.g. the handle was closed) which > jumps back to the cache code and asks that the file be reopened again > (you'll also need to save the current file position before you close > files, of course, so that you can seek back to where you left off when > you "reinstate" a cache entry). Easy. Except that you can't maintain file locks across an LRU this way, so if you have file locks, you get screwed when they are deasserted at close time. Unfortunately, maintaining the lock list in user space is not a real option either, since your close lets someone else lock something you believe you have locked. Then your application goes to do something with a range it believes it has locked, your open succeeds, but the file lock can not be reasserted transparently (ie: the reassertion must block). Even if your application is expecting to potentially block on an operation where you don't really expect a long time blocking to take place, you are still screwed, since if someone came in, locked, modified, and unlocked, then your application data cache is potentially stale, and you have no notification. Not to mention O_EXCL and whole-file locks. 8-). > (please realize that the above is a parody answer in response to an > intentional goad to get SOMEONE to realize that we don't rise to such > bait :-) Heh. That's OK; my response was parody, too. 8-). Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199708032121.OAA02311>