Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Fix dropping TLS for detached futures #139

Merged
merged 1 commit into from
Mar 7, 2024

Conversation

jamesbornholt
Copy link
Member

@jamesbornholt jamesbornholt commented Mar 7, 2024

When a detached future is being cleaned up after the end of an
execution, it won't be able to access the current task's storage any
more. We need to bail out early from the cleanup to avoid a panic.

I also fixed two small issues:

  1. We accidentally took a dependency on tracing 0.1.36 by using a value type in a Span::record call, despite only specifying an earlier version.
  2. The docs weren't building on older smallvec versions because of some const weirdness.

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.

When a detached future is being cleaned up after the end of an
execution, it won't be able to access the current task's storage any
more. We need to bail out early from the cleanup to avoid a panic.
@jamesbornholt jamesbornholt marked this pull request as ready for review March 7, 2024 00:52
Comment on lines +148 to +153
// If we've finished execution already (this task was detached), don't clean up. We
// can't access the state any more to destroy thread locals, and don't want to run
// any more wakers (which will be no-ops anyway).
if ExecutionState::try_with(|state| state.is_finished()).unwrap_or(true) {
return Poll::Ready(());
}
Copy link
Contributor

Choose a reason for hiding this comment

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

Why are we still polling the future if execution already finished?

Was the task's local storage already dropped in ExecutionState::cleanup when we drained tasks?

Copy link
Member Author

@jamesbornholt jamesbornholt Mar 7, 2024

Choose a reason for hiding this comment

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

We're not re-polling the future after execution finishes. But at ExecutionState::cleanup time, we drop the continuation, which for unfinished tasks involves resuming the task so that it can unwind its stack. That's how we end up in this code. We do still clean up the task's local storage inExecutionState::cleanup, so this change isn't actually leaking anything, just changing where the cleanup happens.


struct ShuttleSpawn;

impl Spawn for ShuttleSpawn {
Copy link
Member

Choose a reason for hiding this comment

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

Nice - didn't know about the Spawn trait.

@jorajeev jorajeev merged commit 5c0b694 into awslabs:main Mar 7, 2024
5 checks passed
jamesbornholt added a commit to jamesbornholt/mountpoint-s3 that referenced this pull request Mar 7, 2024
The Shuttle issue was fixed by awslabs/shuttle#139

Signed-off-by: James Bornholt <bornholt@amazon.com>
github-merge-queue bot pushed a commit to awslabs/mountpoint-s3 that referenced this pull request Mar 7, 2024
The Shuttle issue was fixed by awslabs/shuttle#139

Signed-off-by: James Bornholt <bornholt@amazon.com>
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.

3 participants