> From: Paul Smith <psm...@gnu.org> > Cc: David Boyce <david.s.bo...@gmail.com>, f.heckenb...@fh-soft.de, > bug-make@gnu.org > 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. _______________________________________________ Bug-make mailing list Bug-make@gnu.org https://lists.gnu.org/mailman/listinfo/bug-make
