Eli Zaretskii wrote:
That's one way. Another one is to discuss the design more thoroughly
before the patches are accepted.
I think it was discussed quite extensively. Also in retrospect, I
don't see how the design could have been much different (see below).
I tried to turn the discussion
Date: Wed, 24 Apr 2013 05:56:49 +0300
From: Eli Zaretskii e...@gnu.org
Cc: f.heckenb...@fh-soft.de, bug-make@gnu.org
I will see if locking works on console handles; if not, I will have
to introduce a command-line argument for passing the name or the
handle of a mutex to a sub-Make.
As I
Date: Thu, 18 Apr 2013 21:57:56 +0300
From: Eli Zaretskii e...@gnu.org
Cc: bug-make@gnu.org, bo...@kolpackov.net
Date: Thu, 18 Apr 2013 19:09:06 +0200
From: Frank Heckenbach f.heckenb...@fh-soft.de
. calculation of combined_output in start_job_command will need to be
Eli Zaretskii wrote:
I know about this method, but I'm not sure it does what we want here.
The number used by this method is not guaranteed to be unique on some
versions of Windows. More importantly, it only works for disk files,
I don't know whether it reports a meaningful value for the
Some time ago when solving the same problem in a different way we used
semaphores on Windows and Linux. Compatibility might make it less
interesting but I would suggest pretending that one has semaphores first
with some nice little abstraction and then implementing them in the best
way the
On Wed, Apr 24, 2013 at 10:26 AM, Tim Murphy tnmur...@gmail.com wrote:
I would suggest pretending that one has semaphores first with some nice
little abstraction and then implementing them in the best way the platform
has to offer.
How about we introduce functions called acquire_semaphore()
Date: Wed, 24 Apr 2013 18:50:15 +0200
Cc: bug-make@gnu.org
From: Frank Heckenbach f.heckenb...@fh-soft.de
That's one way. Another one is to discuss the design more thoroughly
before the patches are accepted.
I think it was discussed quite extensively. Also in retrospect, I
don't see
Date: Wed, 24 Apr 2013 19:14:01 +0200
Cc: bug-make@gnu.org
From: Frank Heckenbach f.heckenb...@fh-soft.de
Testing clearly shows it doesn't: GetFileInformationByHandle simply
fails for handles open on console devices and the null device. And we
will be comparing handles for console
Date: Wed, 24 Apr 2013 10:34:20 -0700
From: David Boyce david.s.bo...@gmail.com
Cc: Frank Heckenbach f.heckenb...@fh-soft.de,
bug-make@gnu.org bug-make@gnu.org
On Wed, Apr 24, 2013 at 10:26 AM, Tim Murphy tnmur...@gmail.com wrote:
I would suggest pretending that one has
On Wed, 2013-04-24 at 21:17 +0300, Eli Zaretskii wrote:
There's one issue that perhaps needs discussing. A mutex is
identified by a handle, which on Windows is actually a pointer to an
opaque object (maintained by the kernel). As such, using just 'int'
for sync_handle is not wide enough,
Eli Zaretskii wrote:
: Btw, there will be other side effects, at least on non-Posix
: platforms, due to the fact that stuff that was supposed to go to the
: screen is redirected to a file instead. Some programs sense that and
: behave differently, e.g. with binary non-printable
I'm fully prepared to accept the blame for not doing the best job
getting buy-in etc. on this effort. Can we leave the discussion on the
process behind? I'd prefer that, unless there are real constructive
comments on how to do better next time rather than rehashing what was
done wrong. I think
From: Paul Smith psm...@gnu.org
Cc: e...@gnu.org, bug-make@gnu.org
Date: Wed, 24 Apr 2013 15:07:21 -0400
I'm not so sure fstat() is that cheap. struct stat contains a lot of
information. Although I guess since we are only ever talking about temp
files, not NFS files or something, it's
Date: Wed, 24 Apr 2013 20:46:14 +0200
Cc: p...@mad-scientist.net, bug-make@gnu.org
From: Frank Heckenbach f.heckenb...@fh-soft.de
I don't see why it would terminate prematurely
It was long ago, but I presume I thought about the ^Z character that
some programs write or interpret to
On Wed, 2013-04-24 at 22:25 +0300, Eli Zaretskii wrote:
From: Paul Smith psm...@gnu.org
Cc: e...@gnu.org, bug-make@gnu.org
Date: Wed, 24 Apr 2013 15:07:21 -0400
I'm not so sure fstat() is that cheap. struct stat contains a lot of
information. Although I guess since we are only ever
On Wed, 2013-04-24 at 22:39 +0300, Eli Zaretskii wrote:
Nothing is actually read by lseek (and even if it were, it would
only need to look at the first and last part of the file, not read
all the content, if that was the worry).
Are you sure? How can lseek jump to the last byte of the
why not use a named semaphore wherever possible (windows and linux) and
lock a file where not instead of trying to pass kernel object handles
around (seems a bit nasty to me)?
On 24 April 2013 21:19, Paul Smith psm...@gnu.org wrote:
On Wed, 2013-04-24 at 22:39 +0300, Eli Zaretskii wrote:
On Wed, 2013-04-24 at 22:55 +0100, Tim Murphy wrote:
why not use a named semaphore wherever possible (windows and linux)
and lock a file where not instead of trying to pass kernel object
handles around (seems a bit nasty to me)?
Hi Tim; I think you're late to the party :-). Let me summarize a
Paul Smith wrote:
On Wed, 2013-04-24 at 20:46 +0200, Frank Heckenbach wrote:
That's true about SEEK_CUR which was there originally. I actually
changed it to SEEK_END, which does move the position to the end.
Oh right. My head cold is keeping me foggy. What was the reason to
change to
The manual contains this example:
archive.a: ...
ifneq (,$(findstring t,$(MAKEFLAGS)))
+touch archive.a
+ranlib -t archive.a
else
ranlib archive.a
endif
But this would also trigger if you ran make with any other option that
contains a t,
From: Paul Smith p...@mad-scientist.net
Cc: Frank Heckenbach f.heckenb...@fh-soft.de, bug-make@gnu.org
Date: Wed, 24 Apr 2013 16:03:56 -0400
Or maybe we should abandon this optimization and take the lock
regardless. How bad can that be?
Well, we want to know if the file has any
Eli Zaretskii wrote:
From: Paul Smith p...@mad-scientist.net
Cc: Frank Heckenbach f.heckenb...@fh-soft.de, bug-make@gnu.org
Date: Wed, 24 Apr 2013 16:03:56 -0400
Or maybe we should abandon this optimization and take the lock
regardless. How bad can that be?
Well, we want to
Date: Wed, 24 Apr 2013 22:55:59 +0100
From: Tim Murphy tnmur...@gmail.com
Cc: bug-make@gnu.org bug-make@gnu.org
trying to pass kernel object handles around (seems a bit nasty to
me)?
Why is that nasty? The handle is returned by a documented interface,
and communicating it to another
Date: Thu, 25 Apr 2013 02:16:33 +0200
Cc: e...@gnu.org, bug-make@gnu.org
From: Frank Heckenbach f.heckenb...@fh-soft.de
I can't follow you here. On POSIX, we don't need to pass a fd
because it's always stdout/stderr. Or do mean something else?
I meant the file descriptor passed to
Eli Zaretskii wrote:
Date: Thu, 25 Apr 2013 02:16:33 +0200
Cc: e...@gnu.org, bug-make@gnu.org
From: Frank Heckenbach f.heckenb...@fh-soft.de
I can't follow you here. On POSIX, we don't need to pass a fd
because it's always stdout/stderr. Or do mean something else?
I meant
25 matches
Mail list logo
