Re: GNU make 3.81beta4 released

[Paul D. Smith]

%% Eli Zaretskii <address@hidden> writes:

  ez> It is used either as a boolean YES/NO flag, or as a bitmap of
  ez> several flags (see the RM_* flags in dep.h).

Yeah; that dual-use is gross.

  >> Not sure what you mean by "close to the current limit"... how would make
  >> know that?

  ez> I think getrlimit(RLIMIT_NRPOC,...) is a good candidate.

Yes, but that gives the total number of processes for that user... the
number that make can start will be very significantly less than that
under normal circumstances (where you're building on a desktop system
for example).  And of course, in a recursive make situation there's no
telling how many processes the other instances of make will kick off.

I don't see any way to use this limit effectively.  You'll just have to
start things up until something fails and you can't start any more.

  ez> It shouldn't wait, IMHO, just queue the job as if the load were
  ez> too high.  Eventually, when some of the other subprocesses exit,
  ez> there will be a few available process slots, and the queued jobs
  ez> will have their chance.  Just like when the load is too high.

Ah!  Good point.  Yes, that sounds like the way to go.

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