rust: fix whole-runtime deadlock in escape_to_async on multi-thread runtimes - #950
Open
kamalesh0406 wants to merge 1 commit into
Open
rust: fix whole-runtime deadlock in escape_to_async on multi-thread runtimes#950kamalesh0406 wants to merge 1 commit into
kamalesh0406 wants to merge 1 commit into
Conversation
…untimes escape_to_async bridges sync Dafny code back to async on multi-thread tokio runtimes with block_in_place + Handle::block_on, which parks the calling worker on a future that the caller's own runtime must drive. When that worker is the last active one — every other worker parked and the shared IO/timer driver unowned — the bridged future can never make progress and the entire runtime deadlocks permanently: no timers, no IO, no task is ever polled again, unrecoverable without killing the process. tokio's documentation explicitly warns that a future passed to Handle::block_on from within a runtime must not depend on that runtime for progress. Run the future on a scoped thread with a fresh current-thread runtime instead — the same pattern the CurrentThread arm already uses — so the bridged future never depends on the caller's runtime for progress on any flavor. The cost is one thread spawn + runtime build per escaped call, which only happens on key-material cache misses. Fixes the deadlock reported in aws#899.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Issue #899, if available:
Description of changes:
escape_to_async bridges sync Dafny code back to async on multi-thread tokio runtimes with block_in_place + Handle::block_on, which parks the calling worker on a future that the caller's own runtime must drive. When that worker is the last active one — every other worker parked and the shared IO/timer driver unowned — the bridged future can never make progress and the entire runtime deadlocks permanently: no timers, no IO, no task is ever polled again, unrecoverable without killing the process. tokio's documentation explicitly warns that a future passed to Handle::block_on from within a runtime must not depend on that runtime for progress.
Run the future on a scoped thread with a fresh current-thread runtime instead — the same pattern the CurrentThread arm already uses — so the bridged future never depends on the caller's runtime for progress on any flavor. The cost is one thread spawn + runtime build per escaped call, which only happens on key-material cache misses.
Squash/merge commit message, if applicable:
By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.