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 N
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
> bat
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 fi
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 is
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 t
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 inste
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 g
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 cl
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 straightfo
