Re: [bug #33138] .PARLLELSYNC enhancement with patch

[Frank Heckenbach]

(TL;DR: Probably irrelevant.)

Paul Smith wrote:

> I'm not sure if the lock locks the FD (so that if you dup'd the FD but
> it still pointed to the same output, you could take exclusive locks on
> both), or if it locks the underlying resource.  If the former I guess
> it's possible to break the synchrony if you worked at it.

The Linux manpage says:

: As well as being removed by an explicit F_UNLCK, record locks are auto-
: matically released when the process terminates or if it closes any file
: descriptor  referring  to a file on which locks are held.  This is bad:
: it means that a process can lose the locks on a file  like  /etc/passwd
: or  /etc/mtab  when for some reason a library function decides to open,
: read and close it.
:
: Record locks are not inherited by a child created via fork(2), but  are
: preserved across an execve(2).

A quick test indicates that the lock indeed refers to the resource,
but several locks to the same resource are merged by the system
(rather than deadlocking itself):

#include <fcntl.h>

int main ()
{
  int a = open ("/dev/null", O_RDWR);
  int b = open ("/dev/null", O_RDWR);  // or b = dup (a)
  struct flock fl;
  fl.l_type = F_WRLCK;
  fl.l_whence = SEEK_SET;
  fl.l_start = 0;
  fl.l_len = 1;
  if (fcntl (a, F_SETLKW, &fl))
    perror ("a");
  if (fcntl (b, F_SETLKW, &fl))
    perror ("b");
  return 0;
}

Though I don't think any of this really matters, at least with our
current implementation, since we don't dup the FD locked or fork or
exec during this time. And "it's possible break the synchrony if you
worked at it" since our locking is only advisory, anyway. (I.e.,
within make; not so easy in the jobs run since they don't see the FD
used for locking, i.e. the original stdout.)

PS: Paul, the following comment is obsolete; I forgot to remove it:

  fl.l_start = 0; /* lock just one byte according to pid */