[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [bug #60774] make hangs on fcntl lock when using -O and stdout is /d

From: David Boyce
Subject: Re: [bug #60774] make hangs on fcntl lock when using -O and stdout is /dev/null
Date: Sun, 25 Jul 2021 17:29:53 -0700


I don't understand why you say "I don't know of any portable way of determining whether stdout is going to /dev/null, or not" and "However, it's moot because I don't think we can detect it". It's simple to detect this on a Unix-like host (see sample script below) and my contention is that this is "plenty portable enough". The concepts of /dev/null and device/inode both go right back to the very first days of Unix so I think it's almost certain that any Unix-derived or -inspired platform is going to support both. Put differently, I think any system supported by GNU make will have both or neither. But let's imagine a system that has just one of the two: for systems that don't have /dev/null, what's the problem? It can't be locked if it's not there and any system that does implement /dev/null will certainly implement it with the traditional semantics. Native Windows doesn't have /dev/null (and Eli confirms that this can't happen there), Cygwin emulates both, etc. I believe both preconditions are easily detectable at configure time.

Bottom line, the odds of any platform that supports a lockable /dev/null not having st_ino in a stat structure, at least an emulated one, seem vanishingly small to me. Do you know of a platform where the strategy of "implement the special case for /dev/null if possible or retain current semantics if not" breaks down?


$ cat /tmp/null-vs-stdout
#!/usr/bin/env python3
import os
import sys
for path in sys.argv[1:]:
    p = os.stat(path)
    s = os.fstat(sys.stdout.fileno())
    if p.st_ino == s.st_ino and p.st_dev == s.st_dev:
        sys.stderr.write('IS stdout: %s\n' % path)
        sys.stderr.write('not stdout: %s\n' % path)

$ python3 /tmp/null-vs-stdout /dev/null
not stdout: /dev/null

$ python3 /tmp/null-vs-stdout /dev/null > /dev/null
IS stdout: /dev/null

On Sun, Jul 25, 2021 at 1:31 PM Paul Smith <psmith@gnu.org> wrote:
On Sun, 2021-07-25 at 16:04 -0400, Dmitry Goncharov wrote:
> > It's clear that /dev/null is a special case, however, because the
> > order in which data is written to it cannot be detected so what's
> > the point in preserving any order?
> Maybe Mike can tell us.

Based on the bug report I don't think Mike knows.  It didn't appear to
me that he had purposefully locked /dev/null, or was even aware that it
was locked.  Is there something else on his system that's doing it?  Is
it a change to the kernel that cause locks here to hang?  We don't

> > What I'm saying is that IF make can detect that its stdout is going
> > to /dev/null then it shouldn't lock at all, because it's not
> > necessary to do so in order to meet the goals of the -O option, and
> > doing so introduces unnecessary latency in the build.
> Even if we come up with a portable mechanism to detect /dev/null,
> what about other files? What about /dev/stdout or /dev/pts/5? i don't
> think, it is possible or even reasonable to attempt to special case
> all these files.

What I'm trying to say is that even if we do special-case /dev/null we
definitely shouldn't special case other files, because /dev/null is
truly a unique situation which is fundamentally different from
/dev/pts/5 etc., and is deserving of special handling.

However, it's moot because I don't think we can detect it.

> > The  question is what to do about supporting -O on these systems.
> A private temp file will work.

Yes.  It's good to have that capability.

Another option would be to use a POSIX named semaphore.  The advantage
of this is that you don't have to worry about temporary file creation,
permissions, and cleaning up.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]