On Fri, 2005-10-28 at 04:29, [EMAIL PROTECTED] wrote:
> But I don't think there's any parallel make which actually works:
> dmake also has the combinatory explosion issue of allowing a potential
> of NxN jobs running rather than just N.
no, it's worse than that. N^D, where D is the subtree depth.
modern versions of gnu make use a pipe as a counting semaphore to limit
the total number of leaf jobs in a tree of recursive make invocations.
both ends of the pipe are held open in each make subprocess. to
withdraw a token, you do a read of 1 character; to redeposit a token you
write a character.
the algorithm is quite simple:
- given a make -jN, the root make process creates a pipe, and writes
N-1 characters to the pipe.
- one job is free, because your parent holds the token for you.
- all other jobs require withdrawing a token from the pipe
to start, and redepositing one when it's done.
> A proper parallel make, IMHO, does not exist. Such a make would register
> all targets completed and would branch of the right number of jobs for
> those targets which have their dependencies completed; and all sub makes
> will need to communicate about targets.
See also the "recursive make considered harmful" paper:
http://www.pcug.org.au/~millerp/rmch/recu-make-cons-harm.html
(Note also that, for the kernel build at least, the extensive use of
200+ wildcard rules results in an extraordinary number of failed stat(2)
operations by dmake during a build. a different way of finding the
source files would likely be much more efficient..)
- Bill
_______________________________________________
opensolaris-discuss mailing list
opensolaris-discuss@opensolaris.org
