Re: GNU make 3.81beta4 released

[Eli Zaretskii]

> Date: Fri, 20 Jan 2006 13:46:12 -0500
> Cc: address@hidden, address@hidden
> From: "Paul D. Smith" <address@hidden>
> 
>   ez> Unless you agree that we should modify this:
> 
>   ez> g->changed += commands_started - ocommands_started;
> 
>   ez> into this:
> 
>   ez> g->changed = commands_started > ocommands_started;
> 
> I haven't checked where "changed" is used but as long as it's always
> only treated as a boolean value and never as a count that change should
> be made.
> 
> If it ever IS treated as a count then obviously we have more work to do
> to fix the problem... maybe just making this a 32-bit value instead.

It is used either as a boolean YES/NO flag, or as a bitmap of several
flags (see the RM_* flags in dep.h).  The latter usage is mostly in
dep.c; remake.c uses this member only as a boolean flag, at least in
the function we are talking about, update_goal_chain.

>   ez> Sorry, you are right.  What I really meant was that load_too_high
>   ez> (which is indeed in job.c) should check whether the number of jobs
>   ez> is close to the current limit, and if so, it should return
>   ez> non-zero.
> 
> Not sure what you mean by "close to the current limit"... how would make
> know that?

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

> At least on POSIX, it's pretty dynamic where the limit is.

Yes, but getrlimit tracks that limit, right?

>   ez> What happens is that the rule's commands fail because vfork fails with
>   ez> EAGAIN.  So the target is not remade.
> 
> EAGAIN?  Really?   Hm.  Looks like you're right.  Make _should_ handle
> this more gracefully, perhaps by waiting (and ENOMEM as well).
> 
> The problem is there's nothing for make to wait _FOR_; it would just
> have to sleep and then try again... and that has to be worked into
> make's current wait algorithms which are already too complicated.

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

> Please report it on Savannah so we don't lose track.

Will do.