This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: RFC: PATCH to avoid linking multiple front ends at once with parallel make


On 01/05/2013 03:02, Jason Merrill wrote:
> Since GNU Make doesn't support anything like the .MUTEX directive
> (http://savannah.gnu.org/bugs/?func=detailitem&item_id=17873), and
> accidentally doing "make -j8 -l4" makes my laptop useless for several
> minutes while it tries to link all the front ends at once, I decided to
> kludge a workaround.
> 
> This hack uses mkdir as a locking mechanism, as it fails if the
> directory already exists.  Each front-end rule first tries to get the
> lock, and spins if the lock isn't available.  Currently I'm enabling the
> locking by default on build hosts with less than 8GB of memory.
> 
> Releasing the lock is not reliable; if the user interrupts the link with
> ^C, the lock will remain.  So I adjusted 'make all' to remove the lock
> early on, though that only works for the typical case, and users that do
> something like 'make cc1plus' could still run into trouble.
> 
> Thoughts?  Is this too horrible a hack, or does it seem like something
> we might want?
> 
> Maybe I should fix Make instead.

  This sounds like a bad idea to me, and not just because the locking
mechanism is dodgy.  Is the problem more widespread than just your laptop?
Does it affect other host OSs?  Linking multiple frontends at once doesn't
lock up my desktop PC, so I'd rather not have it disabled.

  Why don't you just nice your build shell?  Shouldn't that make the rest of
your system responsive?

    cheers,
      DaveK


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]