Re: [bug #33138] .PARLLELSYNC enhancement with patch

[Paul Smith]

On Tue, 2013-04-16 at 16:43 +0300, Eli Zaretskii wrote:
> > I'm not sure what the semantics of tmpfile() are on Windows.
> 
> The file is automatically deleted when closed.  But the documentation
> doesn't say what happens if it is open on more than one descriptor, or
> what happens if the original descriptor is dup'ed.  I will need to
> test that, and perhaps provide a work-around.

It might be that we have to allow use of a file handle on Windows,
rather than a descriptor.  The original code actually didn't close the
file if dup() failed, but this left the file open forever so I changed
it to fail.  Some portability glue could be added for this.

> Do we even need to lock a file?  If all that's needed is a semaphore
> (actually, a mutex, AFAICS), Windows has good support for that which
> doesn't involve files at all.

Yes a system-wide mutex would be fine.  That's not so easy to do
portably on UNIX systems.  File locking is the most straightforward,
widely-supported means of handling this there.

The descriptor-based mutex has the very slight advantage over a
system-wide mutex in that if a sub-make's output is redirected it now
has its own lock domain.  However I imagine this would happen very
rarely (how many makefiles run sub-makes with stdout/stderr redirected?)
and probably won't have much performance impact anyway.

> This page:
> 
>    http://pubs.opengroup.org/onlinepubs/009695399/functions/fcntl.html
> 
> says, immediately prior to describing F_SETLKW and its friends:
> 
>    The following values for 'cmd' are available for advisory record
>    locking. Record locking shall be supported for regular files, and
>    may be supported for other files.
> 
> I don't know what is the de-facto situation in this regard on Posix
> systems.

Yeah, I saw that too.  I'll try to run some tests on different systems.
If this is not portable enough we'll have to pick a real file, then
communicate the information (file name or descriptor) to sub-makes.

> But this redirection can be changed several times by the commands run
> _after_ the initial decision described above was made: the shell
> commands run by the job can do anything with these two handles, right?
> So it could easily be the case that the output and error streams get
> separated under OUTPUT_SYNC, where they originally appeared together,
> interspersed.

I'm not sure I'm seeing the issue.  Sure, commands in a shell can
redirect their output however they want.  I don't see a situation where
we'd get different behavior than expected.  Can you give a scenario?