- 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:
tchernobog 2006-08-12 17:04:21 +00:00
parent 59edb09c14
commit 9ff7502bb4
3 changed files with 16 additions and 31 deletions

View file

@ -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));
}
}
}