The test case "scheduleRenderJob()" -- while deliberately operated quite artificially with a disabled WorkForce (so the test can check the contents in the queue and then progress manually -- led to discovery of an open gap in the logic: in the (rare) case that a new task is added ''from the outside'' without acquiring the Grooming-Token, then the new task could sit in the entrace queue, in worst case for 50ms, until the next Scheduler-»Tick« routinely sweeps this queue. Under normal conditions however, each dispatch of another activity will also sweep the entrance queue, yet if there happens to be no other task right now, a new task could be stuck. Thinking through this problem also helped to amend some aspects of Grooming-Token handling and clarified the role of the API-functions. |
||
|---|---|---|
| .. | ||
| activity-detector-test.cpp | ||
| activity-detector.hpp | ||
| block-flow-test.cpp | ||
| scheduler-activity-test.cpp | ||
| scheduler-commutator-test.cpp | ||
| scheduler-invocation-test.cpp | ||
| scheduler-load-control-test.cpp | ||
| scheduler-service-test.cpp | ||
| scheduler-stress-test.cpp | ||
| scheduler-usage-test.cpp | ||
| work-force-test.cpp | ||