autoconf-patches
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Update cache files atomically.


From: Eric Blake
Subject: Re: Update cache files atomically.
Date: Tue, 07 Oct 2008 19:51:46 -0600
User-agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.17) Gecko/20080914 Thunderbird/2.0.0.17 Mnenhy/0.7.5.666

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

According to Ralf Wildenhues on 10/7/2008 2:29 PM:
> When several configure scripts run in parallel (in different build
> directories) and share the same config.cache file, there is a race
> condition when saving the cache.  I don't know of a package that does
> this, and the AC_CONFIG_SUBDIRS code doesn't provide this functionality,
> but FWIW here's code that would fix it, by letting the last saver win.
> 
> I've had this on my disk for a long time; the list archives may serve
> just as well.  I don't know whether there is any benefit in using it.
> 
> -    cat confcache >$cache_file
> +      if test -f "$cache_file"; then
> +     mv -f confcache "$cache_file"

That's only atomic if $cache_file resides on the same device as `.' (and
even then, there are deficient file systems like sshfs that can't even do
cross-directory renames, even when both directories are on the same device).

> +      else
> +     cat confcache >"$cache_file"

And that's still racy: consider what happens if process1 starts the cat
process, then process2 sees that the file exists and does the mv, then
process1 completes the cat.  Rather than making this truly atomic, you've
only reduced how often the conflict happens.

So based on that, and on your observation that people generally don't set
shared config.cache, I'm inclined to pass on this for now, leaving the
mail archive as sufficient for anyone who thinks otherwise.  Maybe it's
safer to always 'cp confcache "$cache_file.tmp"', then 'mv
"$cache_file.tmp" "$cache_file"', and skip the cat?  I'm welcome to
further arguments for inclusion or a more robust patch, but am not
bothered enough by it to spend time on it myself.

- --
Don't work too hard, make some time for fun as well!

Eric Blake             address@hidden
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Cygwin)
Comment: Public key at home.comcast.net/~ericblake/eblake.gpg
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkjsEjIACgkQ84KuGfSFAYBcigCglSOWfXzP66hlgQA2AMq5yoc1
Eh8Anjv6wmgmq9BTHl+ucy4WcMdjClbx
=MbnH
-----END PGP SIGNATURE-----




reply via email to

[Prev in Thread] Current Thread [Next in Thread]