On Saturday, July 24, 2021, David Boyce <david.s.bo...@gmail.com> wrote:
> Wouldn’t a less intrusive solution be to check the inode/device of stdout > and if it’s the same as that of /dev/null just forego locking? That would help this specific case indeed. What about a case when make's stdout is redirected to another, not dev null, file? Any file could be locked. Another case is when a child's stdout is redirected to a file different from parent. Regards, Dmitry > > > On Jul 24, 2021, at 11:26 AM, Eli Zaretskii <invalid.nore...@gnu.org> > wrote: > > > > Follow-up Comment #5, bug #60774 (project make): > > > > The MS-Windows port of GNU Make doesn't lock stdout (or any other > standard > > device). Instead, it uses a mutex to synchronize output. So I think > this > > problem cannot happen on Windows. > > > > But I see that your changeset touches quite a few places in the code > which is > > Windows specific, and I wonder why did you have to do that, since the > problem > > you are trying to fix doesn't exist there. Wouldn't it be more prudent > to > > leave the Windows-only code alone? > > > > > > _______________________________________________________ > > > > Reply to this item at: > > > > <https://savannah.gnu.org/bugs/?60774> > > > > _______________________________________________ > > Message sent via Savannah > > https://savannah.gnu.org/ > > > > >
