Paul, 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? David $ 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) else: 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 <psm...@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 > know. > > > > 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. > > > >