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
[email protected] [email protected]
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!
_______________________________________________
desktop-devel-list mailing list
[email protected]
http://mail.gnome.org/mailman/listinfo/desktop-devel-list
