On Thu, Jan 28, 2021 at 6:51 PM Bruno Haible <bruno@xxxxxxxxx> wrote: > Zack Weinberg wrote: > > There is a potential way forward here. The *only* place in all of > > Autoconf and Automake where XFile::lock is used, is by autom4te, to > > take an exclusive lock on the entire contents of autom4te.cache. > > For this, open-file locks are overkill; we could instead use the > > battle-tested technique used by Emacs: symlink sentinels. (See > > https://git.savannah.gnu.org/cgit/emacs.git/tree/src/filelock.c .) > > I can confirm that, while flock() is the most basic/elementary locking > facility [1], its emulation in gnulib [2] does not really work on > Solaris. The unit test regularly fails on Solaris. > > Therefore I like the idea of merely relying on the atomicity of > file creation / file rename operations. > > These files should reside inside the autom4te.cache directory. I would > not like to change all my scripts and Makefiles that do > rm -rf autom4te.cache Agreed. The approach I'm currently considering is: with the implementation of the new locking protocol, autom4te will create a subdirectory of autom4te.cache named after its own version number, and work only in that directory (thus preventing different versions of autom4te from tripping over each other). Each request will be somehow reduced to a strong hash and given a directory named after the hash value. The existence of this directory signals that an autom4te process is working on a request, and the presence of 'request', 'output', and 'traces' files in that directory signals that the cache for that request is valid. If the directory for a request exists but the output files don't, autom4te will busy-wait for up to some definite timeout before stealing the lock and starting to work on that request itself. This would be substantially easier to implement with access to the Storable, Digest::SHA, and Time::HiRes modules, and that's the principal reason I suggested bumping our minimum Perl requirement to 5.18 in <https://lists.gnu.org/archive/html/autoconf/2021-01/msg00133.html>. zw
