> From: Paul Smith <psm...@gnu.org>
> Cc: bo...@kolpackov.net, bug-make@gnu.org, f.heckenb...@fh-soft.de
> Date: Tue, 16 Apr 2013 10:44:39 -0400
>
> 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.
That doesn't matter, really. One can get one from the other on
Windows.
The issue here is whether Windows records the temporary status on the
handle/descriptor, or on some object that is common to all descriptors
for that file. It would make sense for the file to be deleted when
the _last_ descriptor for it is closed, but I'd like to see this in
action first.
> > 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.
I didn't mean a system-wide mutex, I meant a process-wide mutex. Will
this be OK?
> > 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?
E.g., Make sees that both are connected to the same device and
redirects them to the same file, but then the job redirects stderr to
a separate file using shell redirection ("2> foo"). Or vice versa.
_______________________________________________
Bug-make mailing list
Bug-make@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-make
