Re: FreeBSD, autom4te and locking on NFS

[Ralf Wildenhues]

* Alexandre Duret-Lutz wrote on Wed, May 10, 2006 at 10:10:05PM CEST:
> >>> "RW" == Ralf Wildenhues <address@hidden> writes:

>  >> > - BTW, is there real-world indication of build tools other than
>  >> >   Automake-created Makefiles that may happen to invoke parallel autom4te
>  >> >   instances, possibly indirectly?
> 
> I think you can configure autom4te (with "~/.autom4te.cfg") so
> that it creates a central autom4te.cache instead of one per
> project.  If you rebuild several projects in parallel in this
> situation you need locking even without "make -j".

Hmm.  I've thought about this for a while (sorry for the delay),
but I guess it's safe enough.

>  RW> Looks good to me.  Alexandre?
> 
> Looks fine to me, except I would rewrite the last line [...]
> for readability and consistency.

Yep.  Applied like this to Automake, and pulled into Autoconf.

Cheers,
Ralf

2006-05-25  Noah Misch  <address@hidden>

        * lib/Automake/XFile.pm (lock): Allow EOPNOTSUPP, besides
        ENOLCK.  Only mention `make -j' when applicable.  Only raise
        fatal errors when `make -j' is involved.  Improve error message.

Index: lib/Automake/XFile.pm
===================================================================
RCS file: /cvs/automake/automake/lib/Automake/XFile.pm,v
retrieving revision 1.10
diff -u -r1.10 XFile.pm
--- lib/Automake/XFile.pm       14 May 2005 20:28:51 -0000      1.10
+++ lib/Automake/XFile.pm       25 May 2006 10:20:15 -0000
@@ -1,4 +1,4 @@
-# Copyright (C) 2001, 2003, 2004 Free Software Foundation, Inc.
+# Copyright (C) 2001, 2003, 2004, 2006 Free Software Foundation, Inc.
 
 # This program is free software; you can redistribute it and/or modify
 # it under the terms of the GNU General Public License as published by
@@ -91,6 +91,7 @@
 use IO::File;
 use File::Basename;
 use Automake::ChannelDefs;
+use Automake::Channels qw(msg);
 use Automake::FileUtils;
 
 require Exporter;
@@ -218,22 +219,26 @@
   my ($fh, $mode) = @_;
   # Cannot use @_ here.
 
-  # On some systems (e.g. GNU/Linux with NFSv2), flock(2) does not work over
-  # NFS, but Perl prefers that over fcntl(2) if it exists and if
-  # perl was not built with -Ud_flock.  Normally, this problem is harmless,
-  # so ignore the ENOLCK errors that are reported in that situation,
-  # However, if the invoker is using "make -j", the problem is not harmless,
-  # so report it in that case, by inspecting MAKEFLAGS and looking for
-  # any arguments indicating that the invoker used -j.
-  # Admittedly this is a bit of a hack.
-  if (!flock ($fh, $mode)
-      && (!$!{ENOLCK}
-         || (exists $ENV{'MAKEFLAGS'}
-             && " -$ENV{'MAKEFLAGS'}" =~ / (-[BdeikrRsSw]*j|---?jobs)/)))
+  # Unless explicitly configured otherwise, Perl implements its `flock' with 
the
+  # first of flock(2), fcntl(2), or lockf(3) that works.  These can fail on
+  # NFS-backed files, with ENOLCK (GNU/Linux) or EOPNOTSUPP (FreeBSD); we
+  # usually ignore these errors.  If $ENV{MAKEFLAGS} suggests that a parallel
+  # invocation of GNU `make' has invoked the tool we serve, report all locking
+  # failures and abort.
+  #
+  # On Unicos, flock(2) and fcntl(2) over NFS hang indefinitely when `lockd' is
+  # not running.  NetBSD NFS clients silently grant all locks.  We do not
+  # attempt to defend against these dangers.
+  if (!flock ($fh, $mode))
     {
+      my $make_j = (exists $ENV{'MAKEFLAGS'}
+                   && " -$ENV{'MAKEFLAGS'}" =~ / (-[BdeikrRsSw]*j|---?jobs)/);
+      my $note = "\nforgo `make -j' or use a file system that supports locks";
       my $file = $fh->name;
-      fatal ("cannot lock $file with mode $mode "
-            . "(perhaps you are running make -j on a lame NFS client?): $!");
+
+      msg ($make_j ? 'fatal' : 'unsupported',
+          "cannot lock $file with mode $mode: $!" . ($make_j ? $note : ""))
+       if $make_j || !($!{ENOLCK} || $!{EOPNOTSUPP});
     }
 }