bug-make
[Top][All Lists]
Advanced

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

Re: patch to support output synchronization under -j


From: Paul Smith
Subject: Re: patch to support output synchronization under -j
Date: Thu, 14 Apr 2011 14:10:43 -0400

On Thu, 2011-04-14 at 20:48 +0300, Eli Zaretskii wrote:
> > From: Paul Smith <address@hidden>
> > Date: Thu, 14 Apr 2011 13:29:09 -0400
> > 
> > On Thu, 2011-04-14 at 11:01 -0400, David Boyce wrote:
> > > On Tue, Apr 12, 2011 at 1:46 PM, David Boyce <address@hidden> wrote:
> > > > So I've made a proof-of-concept patch
> > > > against 3.82.90 which seems to work without that overhead and my
> > > > question is, would this be of interest towards 3.83?
> > > 
> > > Ping?
> > > 
> > > The original patch attachment was made by hand using "diff -u" and I
> > > had some trouble applying it myself. So here's a version created with
> > > "cvs -q diff -uN" which should work better.
> > 
> > I've looked at it and as a concept I don't have too many issues with it
> > (although I'd like to hear from the ports)
> 
> David, can you explain why you needed to lock the files?  Also, what
> region(s) of the file you are locking?  fcntl with F_WRLCK won't work
> on Windows, so the question is how to emulate it.

David wants to interlock between ALL instances of make printing output,
so that even during recursive makes no matter how many you have running
concurrently, only one will print its output at a time.

There is no specific region of the file that's locked: the lockfile is
basically a file-based, system-wide semaphore.  The entire file is
"locked"; it's empty and has no content.

I'm not sure I like the idea of having to define a lockfile to enable
this feature though.  It feels a little too much like exposing the
implementation details to the user.

> Finally, I'd suggest that the system-dependent portions of sync_output
> be factored out into a separate function, so that the Windows port
> could have its own implementation without infesting job.c with yet
> another bunch of #ifdef's.

Definitely.

-- 
-------------------------------------------------------------------------------
 Paul D. Smith <address@hidden>          Find some GNU make tips at:
 http://www.gnu.org                      http://make.mad-scientist.net
 "Please remain calm...I may be mad, but I am a professional." --Mad Scientist




reply via email to

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