NFS file locking (was: Re: Automake's file locking (was Re: Autoconf/Automake is not using version from AC_INIT))

2021-01-28 Thread pluto--- via Discussion list for automake
Zack Weinberg wrote: > ... > 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 ... > > As I recall, at the time, *neither* flock nor fcntl locks > were honored *at all* over

Re: Automake's file locking (was Re: Autoconf/Automake is not using version from AC_INIT)

2021-01-28 Thread Paul Eggert
On 1/28/21 10:34 AM, Zack Weinberg wrote: 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 .) Although that Emacs code is battle-tested, one of the things it does is fall back on regular

Re: Automake's file locking (was Re: Autoconf/Automake is not using version from AC_INIT)

2021-01-28 Thread Bob Friesenhahn
On Thu, 28 Jan 2021, Nick Bowler wrote: If I understand correctly the issue at hand is multiple concurrent rebuild rules, from a single parallel make implementation, are each invoking autom4te concurrently and since file locking didn't work, they clobber each other and things go wrong. That

Re: Automake's file locking (was Re: Autoconf/Automake is not using version from AC_INIT)

2021-01-28 Thread Bob Friesenhahn
On Thu, 28 Jan 2021, Zack Weinberg wrote: Do you use different versions of autoconf and/or automake on the different clients? No. That would not make sense. If a client is not suitably prepared, then I don't enable maintainer mode. The lock appears to be taken speculatively since it is

Re: Automake's file locking (was Re: Autoconf/Automake is not using version from AC_INIT)

2021-01-28 Thread Nick Bowler
On 2021-01-28, 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

Re: Automake's file locking (was Re: Autoconf/Automake is not using version from AC_INIT)

2021-01-28 Thread Zack Weinberg
On Thu, Jan 28, 2021 at 2:16 PM Bob Friesenhahn wrote: > On Thu, 28 Jan 2021, Zack Weinberg wrote: > > > > 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

Re: Automake's file locking (was Re: Autoconf/Automake is not using version from AC_INIT)

2021-01-28 Thread Bob Friesenhahn
On Thu, 28 Jan 2021, Zack Weinberg wrote: 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

Re: Automake's file locking (was Re: Autoconf/Automake is not using version from AC_INIT)

2021-01-28 Thread Zack Weinberg
On Mon, Jan 25, 2021 at 11:18 AM Bob Friesenhahn 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

Re: Automake's file locking (was Re: Autoconf/Automake is not using version from AC_INIT)

2021-01-25 Thread Bob Friesenhahn
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. Do

Automake's file locking (was Re: Autoconf/Automake is not using version from AC_INIT)

2021-01-25 Thread Zack Weinberg
On Mon, Jan 25, 2021 at 9:52 AM Bob Friesenhahn wrote: > At the moment it is a big deal for me because the locking prototol > that Autoconf/Automake is using does not work with NFS mounts for > Illumos-derived systems when the client is also an Illumos-derived > system, because Illumos failed to