Date: Fri, 19 Apr 2013 11:54:05 +0200
Cc: bo...@kolpackov.net, bug-make@gnu.org
From: Frank Heckenbach f.heckenb...@fh-soft.de
Eli Zaretskii wrote:
Initial investigation indicates that tmpfile should do the job just
fine: the file is deleted only when the last descriptor for it is
Since you asked basic questions I'm going to start this at a basic level.
Apologies if it covers some stuff you already know or if I misinterpreted
the questions. Note that I haven't actually looked at the patch that went
in so this is generally wrt the original.
The first thing is get the word
Date: Tue, 23 Apr 2013 11:29:35 -0700
From: David Boyce david.s.bo...@gmail.com
Cc: Frank Heckenbach f.heckenb...@fh-soft.de, bug-make bug-make@gnu.org
Since you asked basic questions I'm going to start this at a basic level.
Apologies if it covers some stuff you already know or if I
On Tue, 2013-04-23 at 21:40 +0300, Eli Zaretskii wrote:
Date: Tue, 23 Apr 2013 11:29:35 -0700
From: David Boyce david.s.bo...@gmail.com
Cc: Frank Heckenbach f.heckenb...@fh-soft.de, bug-make bug-make@gnu.org
Since you asked basic questions I'm going to start this at a basic level.
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
On Tue, Apr 23, 2013 at 12:04 PM, Paul Smith psm...@gnu.org wrote:
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.
I'm pretty sure it's the underlying
(TL;DR: Probably irrelevant.)
Paul Smith wrote:
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
David Boyce wrote:
The first thing is get the word lock out of your mind because we aren't
really locking anything. Yes, that API is in use but it's only to create a
semaphore or baton. Nobody is ever prevented from doing anything. It just
happens that on Unix the most portable (i.e. oldest)
Date: Tue, 23 Apr 2013 21:41:22 +0200
From: Frank Heckenbach f.heckenb...@fh-soft.de
Yes, as I wrote in another mail, even a completely global semaphore
should do.
Not healthy, IMHO. Some snafu could inadvertently and completely
silently stop an unrelated build somewhere on the same
On Tue, 2013-04-23 at 23:16 +0300, Eli Zaretskii wrote:
All it requires is inheriting the redirected stdout/stderr to child
processes. This was already possible under Dos (with the exception
that since there was no fork, you had to redirect in the parent
process, call the child, then
Eli Zaretskii wrote:
Date: Tue, 23 Apr 2013 21:41:22 +0200
From: Frank Heckenbach f.heckenb...@fh-soft.de
Sure, it's excluding much more than necessary, but since
the critical section is very short, this shouldn't hurt much. (In
other words, if make jobs produce such huge output that
From: Paul Smith p...@mad-scientist.net
Cc: Frank Heckenbach f.heckenb...@fh-soft.de, bug-make@gnu.org
Date: Tue, 23 Apr 2013 16:54:33 -0400
Without knowing what kind of resource Windows can take locks on, we
can't really know how to help with that.
The only resources that don't need their
12 matches
Mail list logo
