Skip to content

Conversation

@teskje
Copy link
Contributor

@teskje teskje commented Dec 16, 2025

To parallelize intensive computation we should use spawn_blocking instead of spawn, to run the computation on a thread where blocking is acceptable.

Motivation

  • This PR refactors existing code.

Tips for reviewer

Checklist

  • This PR has adequate test coverage / QA involvement has been duly considered. (trigger-ci for additional test/nightly runs)
  • This PR has an associated up-to-date design doc, is a design doc (template), or is sufficiently small to not require a design.
  • If this PR evolves an existing $T ⇔ Proto$T mapping (possibly in a backwards-incompatible way), then it is tagged with a T-proto label.
  • If this PR will require changes to cloud orchestration or tests, there is a companion cloud PR to account for those changes that is tagged with the release-blocker label (example).
  • If this PR includes major user-facing behavior changes, I have pinged the relevant PM to schedule a changelog post.

@teskje teskje requested a review from a team as a code owner December 16, 2025 12:44
@teskje teskje requested a review from ggevay December 16, 2025 12:44
To parallelize intensive computation we should use `spawn_blocking`
instead of `spawn`, to run the computation on a thread where blocking is
acceptable.
@teskje teskje force-pushed the view-parse-spawn_blocking branch from 9cde4bb to 71161d3 Compare December 16, 2025 17:35
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