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

[Eli Zaretskii]

> From: Paul Smith <address@hidden>
> Cc: David Boyce <address@hidden>, address@hidden, 
>       address@hidden
> Date: Tue, 23 Apr 2013 15:04:39 -0400
> 
> When thinking about this, remember that it's not enough to consider how
> a single make invocation will work.  If you run with a single make
> instance under -j, then redirecting each job's output to a temp file and
> then when make reaps each job, copying the contents of that temp file to
> stdout, is a sufficient solution.  You just need to be able to redirect
> stdout/stderr of a given job to temporary files.  In UNIX of course this
> is done by dup()'ing the file descriptors after the fork and before the
> exec.  Presumably on Windows there's some other way to do this.

It's the same way, actually (modulo the fork/exec dance).

> So in addition to the temp file change above, you ALSO need a way to
> synchronize the use of the single resource (stdout) that is being shared
> by all instances of recursive make.  On UNIX we have chosen to use an
> advisory lock on the stdout file descriptor: it's handy, and it's the
> resource being contended for, so it makes sense.

I still don't know how does Make achieve on Unix the interlocking with
its sub-Make's.  Is it because the lock is inherited as part of fork?
If so, we will need a special command-line argument on Windows to pass
the name of the mutex, or the value of its handle, down the sub-make
chain, because even if the handle is inherited, its value needs to be
communicated.

(I wish the design and implementation of this feature were less
Posix-centric...)

> I'm not sure if the lock locks the FD (so that if you dup'd the FD but
> it still pointed to the same output, you could take exclusive locks on
> both), or if it locks the underlying resource.  If the former I guess
> it's possible to break the synchrony if you worked at it.

Sorry, you lost me here.