On Sat, 2021-07-24 at 20:35 -0400, Dmitry Goncharov wrote: > On Sat, Jul 24, 2021 at 3:02 PM David Boyce <david.s.bo...@gmail.com> > wrote: > > I can’t think of a file other than /dev/null which would > > appropriately be shared with unrelated processes in a “w” (write) > > condition. > > /dev/zero, /dev/lp0, /dev/lp1, /dev/pts, etc.
/dev/zero should not be written TO, it's only read from. Writing to things like /dev/lp0 SHOULD be locked, IMO: you don't want multiple concurrent writers to your printers or your terminal! To me the most compelling reason to change the current locking behavior is not this: I agree with David that simply special-casing /dev/null could be a good solution; if you're redirecting to /dev/null why even HAVE a lock? Assuming you can determine this it would be better to simply turn it off and avoid the overhead. The most compelling reason to change the current behavior is that unfortunately BSD-based systems don't support locking file descriptors that aren't real files: so if you pipe make's output to something on a BSD-based system like MacOS or FreeBSD, for example, you get a ton of error messages. > i recognize the simplicity of using stdout. However, i also dislike > adding pieces of code for a set of special files. The user will > always find a way to screw it. Using stdout was chosen intentionally because it gives one big advantage, which is why I've struggled with the idea of replacing it: It gives a simple and elegant solution to the situation where a submake's output is redirected to a different file. Suppose you have this: submake: ; $(MAKE) -C $@ >sub.out The way the implementation is today, the outer make and the submake magically have different "output lock domains", because their stdout goes to different files: the submake doesn't have to wait for the lock of the outer make to write content to its output, and vice versa. This is a huge benefit, and I'm loathe to give it up.