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

Better explanation why futures need to be pinned #1687

Merged
merged 1 commit into from
Jan 16, 2024

Conversation

proski
Copy link
Contributor

@proski proski commented Jan 12, 2024

Attempt to address #1677.

Expert review is needed. The new text is my best guess based on the original text and other explanations I could find online.

A few things to note:

  • I'm trying to distinguish the future we return and the future we await. My assumption is that the stack contents goes to the future the code returns, not the future the code is awaiting.
  • Readers could be worried if they need to pin the code they write. I'm reassuring them that the borrow checks would normally catch bad references.
  • I'm intentionally avoiding the words that something is unsafe (or would be unsafe). The async Rust is safe.
  • I'm trying to be clear that Pin is a protective wrapper around a pointer, not a mechanism that changes the pointer or the pointed object.
  • Likewise, I don't want to give an impression that an unpinned pointer to a future is inherently unsafe or invalid. It just cannot be used to poll the future.
  • I dropped the vague mention of the "issues", as it probably refers to the issue with replacing a future (as opposed to resetting it in place). It's already mentioned in the notes further on this page. It affects pinning on stack only, Box::pin() can be replaced.

Comment on lines 4 to 5
trait. When the async code awaits another future, the `Future` trait holds the
local variables that would normally be located on the stack.
Copy link
Collaborator

Choose a reason for hiding this comment

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

I don't think this should be linked to await specifically. My understanding is that the async function body is compiled to a struct which impl Future. What was local variables in the function body become struct fields.

So what you see as a local variable in the code is never actually a variable in the code after the compiler transformation. Thus, I would not say that this happens when you call await since it happened already in the immediate desugaring.

An example of this desugaring can be seen in Async fn as a Future. The State0, State1, and Terminated enum variants correspond to different parts of the now-gone async function body. The variants hold the local variables that are alive in the different parts of the body.

src/async/pitfalls/pin.md Outdated Show resolved Hide resolved
@mgeisler
Copy link
Collaborator

Hi @proski, I really like the new language here, I think it's a nice improvement!

One thing to keep in mind is that the pages are meant to be slides, so they should be brief. Longer explanations are best put in the notes at the bottom of the page (so they can be collapsed during normal teaching). So I would suggest having one 3-line paragraph as the intro text and then expand on that in the notes.

@fw-immunant fw-immunant self-requested a review January 12, 2024 18:50
@proski proski marked this pull request as draft January 12, 2024 19:48
@proski proski force-pushed the pin-future branch 2 times, most recently from 183df78 to bae5185 Compare January 12, 2024 22:28
@proski
Copy link
Contributor Author

proski commented Jan 12, 2024

I reduced the top text to 3 paragraphs and moved some noted to the end.

Thank you for the link to the Tokio documentation, it demystified so many things for me!

I'm not sure why the "Course Schedule Updates" check is failing. I'll keep retrying until the CI check is fixed.

@proski proski marked this pull request as ready for review January 12, 2024 22:33
@mgeisler
Copy link
Collaborator

I reduced the top text to 3 paragraphs and moved some noted to the end.

Cool, I think it looks very nice now! Mentioning "self-referential" is great since it can give people a jumping-off point for further investigation. As @djmitche mentioned in #1678, we cannot expect to teach complex topics like this in detail on slides, but we can at least give people the relevant words to search for later.

Could you include a link to https://doc.rust-lang.org/std/pin/ somewhere (if we don't have it)? That should help people who want more background information.

Thank you for the link to the Tokio documentation, it demystified so many things for me!

Yeah, me too 😄

I'm not sure why the "Course Schedule Updates" check is failing. I'll keep retrying until the CI check is fixed.

Sorry, it's broken on our end... I noticed this yesterday in #1576. We'll probably have to remove the check, but please just ignore it for now.

@mgeisler mgeisler requested a review from djmitche January 15, 2024 08:23
Copy link
Collaborator

@mgeisler mgeisler left a comment

Choose a reason for hiding this comment

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

I like this a lot, @djmitche, do you also want to take a look?

mgeisler added a commit that referenced this pull request Jan 15, 2024
The GitHub action fails because it cannot run with the necessary
permissions: it requires write access to be able to post a comment,
but when triggered from a fork, the token is limited to read access.

The error is from the thollander/actions-comment-pull-request action:

    No comment has been found with asked pattern. Creating a new comment.
    Error: Resource not accessible by integration

The downgrading of the token is explained on:

  https://docs.github.com/en/actions/security-guides/automatic-token-authentication

where “Maximum access for pull requests from public forked
repositories” says that the pull-requests permission is capped at read
in the typical case for us.

I kept the underlying functionality since we might want to use it for
something else (perhaps track the duration in the README).

Fixes the errors seen on the recent PRs: #1693, #1687, and likely
others.
@mgeisler mgeisler mentioned this pull request Jan 15, 2024
mgeisler added a commit that referenced this pull request Jan 15, 2024
The GitHub action fails because it cannot run with the necessary
permissions: it requires write access to be able to post a comment,
but when triggered from a fork, the token is limited to read access.

The error is from the thollander/actions-comment-pull-request action:

    No comment has been found with asked pattern. Creating a new comment.
    Error: Resource not accessible by integration

The downgrading of the token is explained on:

  https://docs.github.com/en/actions/security-guides/automatic-token-authentication

where “Maximum access for pull requests from public forked
repositories” says that the pull-requests permission is capped at read
in the typical case for us.

I kept the underlying functionality since we might want to use it for
something else (perhaps track the duration in the README).

Fixes the errors seen on the recent PRs: #1693, #1687, and likely
others.
mgeisler added a commit that referenced this pull request Jan 15, 2024
The GitHub action added in #1576 fails because it cannot run with the
necessary permissions: it requires write access to be able to post a
comment, but when triggered from a fork, the token is limited to read
access.

The error is from the thollander/actions-comment-pull-request action:

No comment has been found with asked pattern. Creating a new comment.
    Error: Resource not accessible by integration

The downgrading of the token is explained on:

https://docs.github.com/en/actions/security-guides/automatic-token-authentication

where “Maximum access for pull requests from public forked repositories”
says that the pull-requests permission is capped at read in the typical
case for us.

I kept the underlying functionality since we might want to use it for
something else (perhaps track the duration in the README).

Fixes the errors seen on the recent PRs: #1693, #1687, and likely
others.
@mgeisler
Copy link
Collaborator

Thanks for this, let's merge this now and iterate more on it later (if people feel it's needed). @fw-immunant, you'll be teaching the Concurrency class soon, so you might have opnions on this too.

@mgeisler mgeisler merged commit 0a1c30e into google:main Jan 16, 2024
31 checks passed
@proski proski deleted the pin-future branch February 5, 2024 19:19
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