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? _______________________________________________ Bug-make mailing list Bug-make@gnu.org https://lists.gnu.org/mailman/listinfo/bug-make
