[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Eli Zaretskii
Subject: Re: [bug #33138] .PARLLELSYNC enhancement with patch
Date: Tue, 16 Apr 2013 19:20:43 +0300

> From: Paul Smith <address@hidden>
> Cc: address@hidden, address@hidden, address@hidden
> 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

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.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]