Re: SoC idea: desktop file cache

[Alexander Larsson <alexl redhat com>]

On Fri, 2011-03-25 at 11:43 +0000, Alan Cox wrote:
> > > mmap MAP_SHARED also makes dealing with external updating really
> > > interesting because if the file shrinks you need to handle signal
> > > exceptions from touching pages that no longer exist.
> > 
> > Not if the cache is replaced with rename(), no?
> 
> If the sequence is
> 
> 	build new cache
> 	rename
> 	unlink old cache
> 
> then the existing users will continue to see the old file which will only
> vanish completely on the last close. You can use fstat and the like to
> check the size for the mmap to avoid racing the rename on guessing sizes
> etc.

The way I handle this in the gvfs metadata case is to have a "rotated"
int32 in the file header. Then rebuilding does:

fd1 = open("cache"):
create_new_cache("tmp-cache");
rename("tmp-cache", "cache"); // Replaces old cache file atomically
seek (fd1, offset_to_rorated_flag);
write (fd1, 4, buffer_with_ones);

Then, in the public API entry points for reading to the database I
always first check the rotated flag, and if set, re-mmap the file.
This is generally pretty fast, and all clients will eventually move over
to the new file without having to use inotify or some other
mainloop-requiring code.

-- 
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
 Alexander Larsson                                            Red Hat, Inc 
       alexl redhat com            alexander larsson gmail com 
He's an unconventional albino shaman on the wrong side of the law. She's a 
mentally unstable impetuous college professor on the trail of a serial killer. 
They fight crime!