# Objective - Systems that use the task pool, either explicitly or implicitly using parallel queries, will often end up executing tasks from different systems. - This can cause random tasks to block the main or render schedule at random, adding frame variance and increasing frame times when CPU bound. - This profile is a common occurrence on `main`. `propagate_parent_transforms` takes more than twice as long as it should, blocking the main schedule for that time, because it uses `task pool.scope`, which has decided to execute tasks from the render schedule on the main schedule.  ## Solution - In task pool scope execution, prefer to check if the current task is complete instead of ticking the executor to find new work. ## Testing - Ran the scene viewer with tracy to look for images like the one in the objective section. - Things look much, much better, and I could not find any occurrences:   |
||
|---|---|---|
| .. | ||
| iter | ||
| executor.rs | ||
| futures.rs | ||
| lib.rs | ||
| single_threaded_task_pool.rs | ||
| slice.rs | ||
| task_pool.rs | ||
| task.rs | ||
| thread_executor.rs | ||
| usages.rs | ||
| wasm_task.rs | ||