-- Forwarded message --
From: Tim Murphy
Date: 25 April 2013 07:13
Subject: Re: [bug #33138] .PARLLELSYNC enhancement with patch
To: "Paul D. Smith"
To be honest, I have done all this before with named semaphores including
the "file that gets left over" problem and it's all solv
Eli Zaretskii wrote:
> > Date: Thu, 25 Apr 2013 02:16:33 +0200
> > Cc: e...@gnu.org, bug-make@gnu.org
> > From: Frank Heckenbach
> >
> > > > 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 th
> Date: Thu, 25 Apr 2013 02:16:33 +0200
> Cc: e...@gnu.org, bug-make@gnu.org
> From: Frank Heckenbach
>
> > > 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 fcntl to p
> Date: Wed, 24 Apr 2013 22:55:59 +0100
> From: Tim Murphy
> Cc: "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 process is an officially documen
Eli Zaretskii wrote:
> > From: Paul Smith
> > Cc: Frank Heckenbach , 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 cont
> From: Paul Smith
> Cc: Frank Heckenbach , 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 content anyway: for example we
> don't wan
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"
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
> chan
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
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 wrote:
> On Wed, 2013-04-24 at 22:39 +0300, Eli Zaretskii wrote:
> > > Nothing is ac
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
On Wed, 2013-04-24 at 22:25 +0300, Eli Zaretskii wrote:
> > From: Paul Smith
> > 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 tal
> Date: Wed, 24 Apr 2013 20:46:14 +0200
> Cc: p...@mad-scientist.net, bug-make@gnu.org
> From: Frank Heckenbach
>
> > > 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 signal end o
> From: Paul Smith
> 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 probably n
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 w
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 ch
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,
> Date: Wed, 24 Apr 2013 10:34:20 -0700
> From: David Boyce
> Cc: Frank Heckenbach ,
> "bug-make@gnu.org"
>
> On Wed, Apr 24, 2013 at 10:26 AM, Tim Murphy wrote:
>
> > I would suggest pretending that one has semaphores first with some nice
> > little abstraction and then implementing th
> Date: Wed, 24 Apr 2013 19:14:01 +0200
> Cc: bug-make@gnu.org
> From: Frank Heckenbach
>
> > 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 devices in the maj
> Date: Wed, 24 Apr 2013 18:50:15 +0200
> Cc: bug-make@gnu.org
> From: Frank Heckenbach
>
> > 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 desig
On Wed, Apr 24, 2013 at 10:26 AM, Tim Murphy 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() and
release_se
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 platform
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
> Date: Thu, 18 Apr 2013 21:57:56 +0300
> From: Eli Zaretskii
> Cc: bug-make@gnu.org, bo...@kolpackov.net
>
> > Date: Thu, 18 Apr 2013 19:09:06 +0200
> > From: Frank Heckenbach
> >
> > > . calculation of combined_output in start_job_command will need to be
> > >reimplemented for Windows, s
> Date: Wed, 24 Apr 2013 05:56:49 +0300
> From: Eli Zaretskii
> 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 suspect
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
26 matches
Mail list logo
