bug-make
[Top][All Lists]
Advanced

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

Re: Fwd: [RFC]serialize the output of parallel make?


From: Howard Chu
Subject: Re: Fwd: [RFC]serialize the output of parallel make?
Date: Tue, 03 Aug 2010 01:40:51 -0700
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; rv:1.9.3a6pre) Gecko/20100708 Firefox 3.6

Chiheng Xu wrote:
On Tue, Aug 3, 2010 at 2:51 PM, Tim Murphy<address@hidden>  wrote:

Since some things happen at the same time there is no single "serial
order".  The semaphore mechanism, forces one of the possible orders.

I'm not familiar with source code of make, but I believe the "serial
order" of shells is determined by the dependence DAG,  it may be
unique for a given dependence DAG.

Shells can be issued and completed at random order(only need
satisfying the dependence relation). But make can print their outputs
strictly in their "serial order".

I'm trying very hard to only provide constructive comments in response to this thread, but frankly this is, in a word, stupid.

If you want make's output to be in serial order, then don't use parallel make at all. The point to parallel make is that it allows jobs which have no ordering dependency to run in parallel. If you want their output to be fully serialized, then you will force make to wait for them to complete serially. Which automatically also means that make will have to maintain an arbitrarily large internal queue for all of the output, because given the unpredictable completion times of multiple jobs running concurrently, no output can be emitted until the slowest parallel job completes. In particular, if you have recursive makefiles, no parent make process can output anything at all until all of its submakes have completed, because no individual make process has enough knowledge about what the actual serial order is.

Given that this discussion seems to have arisen due to the braindead stdio handling in Cygwin, it seems like any de-mangling of parallel make's output should be directed to the Cygwin libraries. In my experience Cygwin is too slow an environment to be useful anyway, which is why I use MSYS for Windows builds. But I have to admit, I only use it inside a single-core VirtualBox these days so I haven't looked at how parallel make behaves there. But the fact is all I/O in Cygwin is funneled through the Cygwin DLL, so there's no reason that it can't be fixed to not mingle/mangle lines from different processes together. But again, that's not gnu-make's problem, that's a Cygwin issue.

--
  -- Howard Chu
  CTO, Symas Corp.           http://www.symas.com
  Director, Highland Sun     http://highlandsun.com/hyc/
  Chief Architect, OpenLDAP  http://www.openldap.org/project/



reply via email to

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