On Tue, Feb 01, 2000 at 10:44:05PM -0600, Dan Potter was heard to say: > Actually it looks like it works ok (at least on read-only, I haven't > managed to get far enough through apt to test it fully). It's really brute > force though =). It just reads the whole file into memory and then lets > you poke at it. If you do a msync() then it writes the whole file to disk. > Probably will break when I get further into testing this, and definitely > not optimal, but... =) > > You can probably tell that I haven't really worked with mmap() so there > are going to be some catches in there. Like if you close the fd after > mmap()'ing, or the file changes on disk, etc...
Cool. As you said, it's not as optimal -- but I don't know just how bad it is :) It's either much less or much more resiliant to a crash of apt itself (uncommitted changes will be lost, could be good or bad), and may not be that much less efficient in time at startup (instead of backing the memory with the file, you're backing it with swap, and I think that Apt already iterates through the cache once on startup, which is likely to bring most pages into memory (?) ) You actually don't have to worry about closing the fd; as I recall, the open file will retain a reference in the map list for the process (or whatever BSD does). Changes to the disk file will be immediately reflected in a normal shared map, but APT locks its files so that only one process at a time can modify them anyway (more than one can read from them at a time..) Daniel -- "...drums...drums in the deep!" J. R. R. Tolkien
