%% Eli Zaretskii <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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 _______________________________________________ Make-w32 mailing list [email protected] http://lists.gnu.org/mailman/listinfo/make-w32
