Skip to content

Earlier exit for sim thread#917

Merged
ZanCorDX merged 3 commits intodevelopfrom
dx/stop-sims-earlier
Apr 15, 2026
Merged

Earlier exit for sim thread#917
ZanCorDX merged 3 commits intodevelopfrom
dx/stop-sims-earlier

Conversation

@ZanCorDX
Copy link
Copy Markdown
Collaborator

📝 Summary

This changes makes the sim thread finish as soon as the block ends.

💡 Motivation and Context

Saw on a test version lots of sims happening after the block ended.

✅ I have completed the following steps:

  • Run make lint
  • Run make test
  • Added tests (if applicable)

@ZanCorDX ZanCorDX requested a review from dvush as a code owner April 15, 2026 17:20
@claude
Copy link
Copy Markdown
Contributor

claude bot commented Apr 15, 2026

Claude finished @ZanCorDX's task in 2m 58s —— View job


PR Review: Earlier exit for sim thread

  • Gather context and read changed files
  • Review code changes for correctness and edge cases
  • Post review findings

Summary

The intent is sound — checking results.is_closed() to avoid wasted simulation work after a block ends is a good optimization, and the improved try_send error handling (logging Full instead of silently swallowing all errors) is a nice cleanup.

Issue found

return should be break (sim_worker.rs:63-64) — The return kills the worker thread permanently instead of sending it back to the 'main loop to wait for the next block's SimulationContext. Over successive blocks, this would drain the worker pool as threads that happen to dequeue a request after the results channel closes would exit forever. See inline comment for details.

Fix this →

// Avoid starting sims when the output channel is closed.
if current_sim_context.results.is_closed() {
return;
}
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Bug: return here kills the worker thread permanently. The 'main loop in run_sim_worker is designed to keep workers alive across block boundaries — they wait for a new SimulationContext after the current one is done. When results.is_closed() (i.e. the SimulationJob dropped its receiver because the block ended), the worker should go back to 'main to pick up the next block's context, not exit.

After this change, each time a block ends, any worker that happens to dequeue a request after the results channel closes would be permanently lost. Over time this drains the worker pool.

Should be break instead of return — that exits the inner while loop and naturally falls through to the next 'main iteration, consistent with the existing exit path when requests.recv() returns Err.

@claude
Copy link
Copy Markdown
Contributor

claude bot commented Apr 15, 2026

Claude finished @ZanCorDX's task in 1m 37s —— View job


PR Review: Earlier exit for sim thread (re-review after fix)

  • Gather context and read changed files
  • Review code changes for correctness and edge cases
  • Post review findings

Summary

The previous review's concern (returnbreak) has been addressed in commit 7032906. Reviewed the full diff against develop — no further issues found.

is_closed() early exit (sim_worker.rs:60-64): Correctly avoids starting a simulation after the block ends. Using break sends the worker back to 'main to pick up the next block context, preserving the thread pool.

try_send error handling (sim_worker.rs:93-100): Good improvement — Full is logged with the order ID instead of being silently swallowed. Closed is intentionally ignored since the is_closed() check on the next loop iteration handles a clean exit. One simulation may still complete after the channel closes (TOCTOU gap between the check and try_send), but this is benign — at most one extra sim per worker per block boundary.

Comment (mod.rs:41): Documents the dual role of the results channel as a cancellation signal. Helpful for future readers.

No issues to flag.

@ZanCorDX ZanCorDX merged commit 47533b4 into develop Apr 15, 2026
7 checks passed
@ZanCorDX ZanCorDX deleted the dx/stop-sims-earlier branch April 15, 2026 18:09
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants