[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Bug in update_goal_chain() logic in make 3.79.1
From: |
Patrick J. LoPresti |
Subject: |
Re: Bug in update_goal_chain() logic in make 3.79.1 |
Date: |
08 May 2001 21:17:35 -0400 |
User-agent: |
Gnus/5.0808 (Gnus v5.8.8) Emacs/20.7 |
"Paul D. Smith" <address@hidden> writes:
> pjl> That is, when the job is being placed on the waiting chain
> pjl> because the load is too high, start_job_command() is never
> pjl> called.
>
> That's not true, though: you didn't examine what happens to those jobs
> _after_ they get put on the waiting chain.
>
> Later they're taken off the chain and start_waiting_job() is invoked
> with each of the waiting jobs, and (assuming it doesn't go _back_ on the
> waiting chain) start_job_command() will be run on it at that time, and
> commands_started will be incremented then.
Right, but that is too late to be of any use to the code in
update_goal_chain() which relies on the variable.
Look again at how commands_started is used... It is saved away in
ocommands_started, then update_file() is called, then the value of
commands_started is compared to ocommands_started to update the value
of g->changed.
The result is that g->changed is zero even when commands are invoked
to update the target, if the commands are deferred because the load
average is too high.
Basically, if you carefully examine how commands_started is actually
used, it does not make a lot of sense.
- Pat