[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [bug #33138] .PARLLELSYNC enhancement with patch
From: |
Paul Smith |
Subject: |
Re: [bug #33138] .PARLLELSYNC enhancement with patch |
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. 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 #33138] .PARLLELSYNC enhancement with patch, (continued)
- [bug #33138] .PARLLELSYNC enhancement with patch, Paul D. Smith, 2013/04/16
- Re: [bug #33138] .PARLLELSYNC enhancement with patch, Eli Zaretskii, 2013/04/16
- Message not available
- Re: [bug #33138] .PARLLELSYNC enhancement with patch, Tim Murphy, 2013/04/16
- Re: [bug #33138] .PARLLELSYNC enhancement with patch, Paul Smith, 2013/04/16
- Re: [bug #33138] .PARLLELSYNC enhancement with patch, Paul Smith, 2013/04/16
- Re: [bug #33138] .PARLLELSYNC enhancement with patch, Tim Murphy, 2013/04/16
- Re: [bug #33138] .PARLLELSYNC enhancement with patch, Paul Smith, 2013/04/16
- Message not available
- Re: [bug #33138] .PARLLELSYNC enhancement with patch, Eli Zaretskii, 2013/04/16
- Re: [bug #33138] .PARLLELSYNC enhancement with patch, Paul Smith, 2013/04/16
- Re: [bug #33138] .PARLLELSYNC enhancement with patch, Eli Zaretskii, 2013/04/16
- Re: [bug #33138] .PARLLELSYNC enhancement with patch,
Paul Smith <=
- Re: [bug #33138] .PARLLELSYNC enhancement with patch, Eli Zaretskii, 2013/04/16
- Re: [bug #33138] .PARLLELSYNC enhancement with patch, Paul Smith, 2013/04/16
- Re: [bug #33138] .PARLLELSYNC enhancement with patch, Eli Zaretskii, 2013/04/17
- Re: [bug #33138] .PARLLELSYNC enhancement with patch, Paul Smith, 2013/04/17
- Re: [bug #33138] .PARLLELSYNC enhancement with patch, Eli Zaretskii, 2013/04/17
- Re: [bug #33138] .PARLLELSYNC enhancement with patch, Paul Smith, 2013/04/17
- Re: [bug #33138] .PARLLELSYNC enhancement with patch, David Boyce, 2013/04/17
- Re: [bug #33138] .PARLLELSYNC enhancement with patch, Frank Heckenbach, 2013/04/18
- Re: [bug #33138] .PARLLELSYNC enhancement with patch, Paul Smith, 2013/04/18
- Re: [bug #33138] .PARLLELSYNC enhancement with patch, Frank Heckenbach, 2013/04/18