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.
