(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 */ _______________________________________________ Bug-make mailing list Bug-make@gnu.org https://lists.gnu.org/mailman/listinfo/bug-make