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.
