Make CACHE_ITEM_NEXT go (mostly) away
brong at fastmail.fm
Thu Mar 12 07:58:52 EDT 2009
I'm sick of that interface. It blows. Random memory jumps
trusting stuff in an mmaped file leads to reading from pretty
much anywhere. At least we don't try to write!
Still, segfaults galore.
This doesn't change the fact that index.c is a copy-paster's
enterprisy paradise, but at least it gives named access to
all the bits of the cache record!
The basic concept is this:
struct cacheitem contains a length and a string pointer
typedef cacherecord is 10 items (per NUMCACHEITEMS constant)
ALL access goes through cache_parserecord() in one way or
another (note: this is going to come in real handy if I
ever resurrect checksummed cache records!)
cache_parserecord fills a 'cacherecord' datastructure, and
it returns the length of the full cacherecord (handy, you
can just pass a null cacherecord pointer and get the size).
If it returns a length of zero then the cache is bogus, so
cacherecord is undefined.
With that said - anyone feel like glancing through this code
and seeing that it makes sense? I've only compile tested it
so far, not even run up a test box...
(also available as the "cacherewrite" branch on github)
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 50853 bytes
Desc: not available
Url : http://lists.andrew.cmu.edu/pipermail/cyrus-devel/attachments/20090312/6f5935c8/attachment-0001.bin
More information about the Cyrus-devel