On Mon, Jan 25, 2021 at 11:18 AM Bob Friesenhahn <bfriesen@xxxxxxxxxxxxxxxxxxx> wrote: > On Mon, 25 Jan 2021, Zack Weinberg wrote: > > Automake "just" calls Perl's 'flock' built-in (see 'sub lock' in > > Automake/XFile.pm) (this code is copied into Autoconf under the > > Autom4te:: namespace). It would be relatively straightforward to > > teach it to try 'fcntl(F_SETLKW, ...)' if that fails. I was wrong about this. It is not practical to make a Perl program directly call ‘fcntl(F_SETLKW)’ without use of CPAN modules. This is because, at the C level, ‘fcntl(F_SETLKW)’ takes a ‘struct flock’ argument, and we have no way of knowing what the layout of that structure is. (See https://metacpan.org/pod/File%3a%3aFcntlLock for gory details. We can’t adopt the implementation of that module, because it relies on running a C compiler, and the locking is needed at a point when we do not yet know whether a C compiler is available.) > It may be that moving forward to 'fcntl(F_SETLKW, ...)' by default and > then falling back to legacy 'flock' would be best. Or perhaps > discarding use of legacy 'flock' entirely. > > Most likely the decision as to what to do was based on what was the > oldest primitive supported at the time. I need to reemphasize that the decision here was made by the Perl developers, not the Automake or Autoconf developers, and it was made a very long time ago—judging by e.g. references to h2ph in ‘perldoc Fcntl’, probably circa perl 5.000! I am also going to guess that the motivation for preferring flock was related to the motivation for this grumpy aside in OpenBSD’s ‘fcntl(2)’ manpage: | This interface follows the completely stupid semantics of System V | and IEEE Std 1003.1-1988 (“POSIX.1”) that require that *all* locks | associated with a file for a given process are removed when *any* file | descriptor for that file is closed by that process | ... | The flock(2) interface has much more rational last close semantics (Emphasis in original.) As I recall, at the time, *neither* flock nor fcntl locks were honored *at all* over NFS, so that wouldn’t have been a consideration. ---- 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 .) The main reason I can think of, not to do this, is that it would make the locking strategy incompatible with that used by older autom4te; this could come up, for instance, if you’ve got your source directory on NFS and you’re building on two different clients in two different build directories. On the other hand, this kind of version skew is going to cause problems anyway when they fight over who gets to write generated scripts to the source directory, so maybe it would be ok to declare “don’t do that” and move on. What do others think? zw
