Re: [bug #17873] .NOTPARALLEL enhancements

[Paul Smith]

On Fri, 2012-07-06 at 22:36 +0200, Reinier Post wrote:
> On Fri, Jul 06, 2012 at 03:19:11PM +0000, Jason Merrill wrote:
> 
> [...]
> 
> > I note that patch #5108 seems to create a single global mutex, whereas the
> > documentation for the SCO .MUTEX target suggests that each occurrence of
> > .MUTEX creates a separate mutex, so that given
> > 
> > .MUTEX: this that
> > .MUTEX: yours mine
> 
> Yikes - isn't make complicated enough?
> 
> Isn't there a straightforward way to handle this
> that better fits with the Unix toolbox philosophy?
> 
> E.g. by using a wrapper command to handle the mutual exclusion?
> Something like
> 
>       with-pidfile /tmp/ld.pid $(LD) ...

Most GNU/Linux (at least) systems provide the flock(1) command which can
be used for this purpose.  Something like:

        flock -x $(LOCKFILE) $(LD) ...

There is some trickery required to get a good lockfile name, because you
want it to be the same for all flock commands within this (potentially
recursive!) build but different (one assumes) from lock files in any
other builds which are running concurrently.  You could try something
like:

        export _MASTERPID ?= $(shell echo $$PPID)
        MASTERPID := $(_MASTERPID)
        LOCKFILE := /tmp/linklock.$(MASTERPID)

(untested).

The downside (?) is that make will think that those commands are
actually running and it won't try to schedule other jobs, which cuts
down on your parallelism.  If make handled the mutexes internally then
it could run other jobs that weren't involved in the mutex while
waiting.

Just a thought...