This makes it much more flexible, at the expense of making it a little
more fragile. I can think of a number of scenarios where we'll have
paths that have variables in multiple spots, and I don't want to do
sprintf() magic every time I need to access an object at one of those
paths.
This requires hanging onto an open file handle, and doesn't require
explicit unlocking, because POSIX says files are unlocked when their
descriptors are closed.
- Items that are too big for the cache are now no longer immediately
evicted; everything else is. This is probably not desirable, but it is
not unexpected.
- Multithreading now should work as expected; DbRefs are locked before
they are updated from the disk, and they are not evicted from the cache
if they are locked by another thread.
- The cache may be no smaller than 1024 bytes. Previously the caller of
DbOpen() could choose to disable the cache, and provisions were made in
the code to support this, but this is now no longer possible because
without the cache, there would be no way to know what files were open,
which could lead to a race condition if two threads open the same file.
This also makes UtilGetDelim() and UtilGetLine() thread safe in that it
isn't setting a global errno. Of course, errno should be thread safe
already, but this makes it much less ambiguous.
This has some bugs in it that I don't have time to work out right
now. Best to revert to a known working version as the project gains
attention until I can address this properly.
This will eventually enable us to get memory information in O(1) time.
Right now, we're still O(n) because MemoryInfoGet() still has to check to
see if the allocation is known or not.
