Re: [bug #60774] make hangs on fcntl lock when using -O and stdout is /dev/null

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

Re: [bug #60774] make hangs on fcntl lock when using -O and stdout is /dev/null

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

Re: [bug #60774] make hangs on fcntl lock when using -O and stdout is /dev/null

On Sun, Jul 25, 2021 at 3:25 PM Paul Smith wrote: > I have no problem with make refusing to write to a device that's locked > in general. If users don't want that to happen, they can just not use > the -O option. True, as long as the user knows that when -O is specified make is going to lock

Re: [bug #60774] make hangs on fcntl lock when using -O and stdout is /dev/null

On Sun, 2021-07-25 at 15:25 -0400, Paul Smith wrote: > There's no reason that those two disjoint sets of output need to be > synchronized WITH EACH OTHER to meet the goal of the -O option. Given > the choice between allowing output to go to these two different > locations in parallel vs.

Re: [bug #60774] make hangs on fcntl lock when using -O and stdout is /dev/null

On Sun, 2021-07-25 at 13:11 -0400, Dmitry Goncharov wrote: > On Sun, Jul 25, 2021 at 10:03 AM Paul Smith wrote: > > Writing to things like /dev/lp0 SHOULD be locked, IMO: you don't > > want multiple concurrent writers to your printers or your terminal! > > The user intentionally redirects make

[bug #60774] make hangs on fcntl lock when using -O and stdout is /dev/null

Additional Item Attachment, bug #60774 (project make): File name: sv_60774_output_sync_deadlock_fix2.diff Size:6 KB ___ Reply to this item at:

Re: [bug #60774] make hangs on fcntl lock when using -O and stdout is /dev/null

On Sun, Jul 25, 2021 at 10:03 AM Paul Smith wrote: > Writing to > things like /dev/lp0 SHOULD be locked, IMO: you don't want multiple > concurrent writers to your printers or your terminal! The user intentionally redirects make to a printer along with another tool. Should make be smarter than

Re: [bug #60774] make hangs on fcntl lock when using -O and stdout is /dev/null

On Sun, Jul 25, 2021 at 3:49 AM Eli Zaretskii wrote: > > Follow-up Comment #8, bug #60774 (project make): > > Why did you remove the code which reused the mutex passed from the parent > Make? Eli, i don't think i removed any code, other than the global variable mutex_handle. Atleast, not

[bug #60774] make hangs on fcntl lock when using -O and stdout is /dev/null

Follow-up Comment #9, bug #60774 (project make): i was able to test on windows and attached a proposed patch. The patch does what is described in update 3. ___ Reply to this item at:

[bug #60774] make hangs on fcntl lock when using -O and stdout is /dev/null

Additional Item Attachment, bug #60774 (project make): File name: sv_60774_output_sync_deadlock_fix.diff Size:6 KB ___ Reply to this item at:

Re: [bug #60774] make hangs on fcntl lock when using -O and stdout is /dev/null

On Sat, 2021-07-24 at 20:35 -0400, Dmitry Goncharov wrote: > On Sat, Jul 24, 2021 at 3:02 PM David Boyce > 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,

[bug #60774] make hangs on fcntl lock when using -O and stdout is /dev/null

Follow-up Comment #8, bug #60774 (project make): Why did you remove the code which reused the mutex passed from the parent Make? ___ Reply to this item at:

Re: [bug #60774] make hangs on fcntl lock when using -O and stdout is /dev/null

> From: Dmitry Goncharov > Date: Sat, 24 Jul 2021 22:03:37 -0400 > Cc: Mike Frysinger , Paul Smith , > bo...@kolpackov.net, > bug-make > > Wanted to test that windows this still works with this change. > > So, i followed instructions in README.W32. > Installed mingw gcc. Copied