- This was an *evil* "chicken-or-egg-first" bug in CPUPoliciesGatekeeper. Now
CPUPolicy->activate() should run properly. git-svn-id: svn://svn.gna.org/svn/sgpemv2/trunk@846 3ecf2c5c-341e-0410-92b4-d18e462d057c
This commit is contained in:
parent
59edb09c14
commit
9ff7502bb4
3 changed files with 16 additions and 31 deletions
|
@ -109,15 +109,23 @@ CPUPoliciesGatekeeper::activate_policy(History *history, CPUPolicy* policy)
|
|||
{
|
||||
try
|
||||
{
|
||||
policy->activate();
|
||||
// policy->activate() needs already an active policy, because:
|
||||
// * it calls the configure() method on the
|
||||
// insert-your-favourite-scripting-language-here-policy
|
||||
// * which in turn calls the configure() method in the
|
||||
// code written by the user
|
||||
// * which probably uses Simulation to get the _active_ C++ policy,
|
||||
// so it can get its policy_parameters()
|
||||
// ... so **DON'T** play Mr. Clever Dick and swap the following two
|
||||
// lines in an optimization frenzy! Or the user policy WILL fail.
|
||||
_active_policies[history] = policy;
|
||||
policy->activate();
|
||||
}
|
||||
catch(const CPUPolicyException& e)
|
||||
{
|
||||
//FIXME what to do here???
|
||||
//probably throwing again a MalformedPolicyException
|
||||
//maybe the best idea. or can we just fallback
|
||||
//to the previous policy?
|
||||
// See the comment above to understand why we do this
|
||||
// in this way
|
||||
_active_policies.erase(_active_policies.find(history));
|
||||
}
|
||||
}
|
||||
}
|
||||
|
|
Loading…
Add table
Add a link
Reference in a new issue