Skip to content

Add #[inline] to RawWaker::new #74791

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

Merged
merged 1 commit into from
Jul 29, 2020
Merged

Conversation

tmiasko
Copy link
Contributor

@tmiasko tmiasko commented Jul 26, 2020

RawWaker::new is used when creating a new waker or cloning an existing one,
for example as in code below. The RawWakerVTable::new can be const evaluated,
but RawWaker::new itself cannot since waker pointer is not known at compile
time. Add #[inline] to avoid overhead of a function call.

unsafe fn clone_waker<W: Wake + Send + Sync + 'static>(waker: *const ()) -> RawWaker {
    unsafe { Arc::incr_strong_count(waker as *const W) };
    RawWaker::new(
        waker as *const (),
        &RawWakerVTable::new(clone_waker::<W>, wake::<W>, wake_by_ref::<W>, drop_waker::<W>),
    )
}

@rust-highfive
Copy link
Contributor

r? @LukasKalbertodt

(rust_highfive has picked a reviewer for you, use r? to override)

@rust-highfive rust-highfive added the S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. label Jul 26, 2020
Copy link
Contributor

@KodrAus KodrAus left a comment

Choose a reason for hiding this comment

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

Since this method is const is there a reason to inline it?

@tmiasko
Copy link
Contributor Author

tmiasko commented Jul 27, 2020

The data pointer is usually different for each task and determined at runtime,
so it generally cannot be const evaluated. In contrast to say RawWakerVTable::new
down below.

This is something I noticed while examining the perf report.

@bors
Copy link
Collaborator

bors commented Jul 28, 2020

☔ The latest upstream changes (presumably #73265) made this pull request unmergeable. Please resolve the merge conflicts.

@tmiasko tmiasko force-pushed the raw-waker-inline branch from e76636b to 0a51a9f Compare July 28, 2020 04:15
@LukasKalbertodt
Copy link
Member

Seems reasonable.

@bors r+ rollup=always

@bors
Copy link
Collaborator

bors commented Jul 28, 2020

📌 Commit 0a51a9f has been approved by LukasKalbertodt

@bors bors added S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Jul 28, 2020
@JohnTitor
Copy link
Member

I think this may affect perf and shouldn't be rollup=always but rollup=never?

@LukasKalbertodt
Copy link
Member

Thanks for catching that. I forgot about it. Can I simply change it after approving it like this?

@bors rollup=never

@JohnTitor
Copy link
Member

Can I simply change it after approving it like this?

Yep, it works.

@bors
Copy link
Collaborator

bors commented Jul 28, 2020

⌛ Testing commit 0a51a9f with merge 4cca950...

@bors
Copy link
Collaborator

bors commented Jul 29, 2020

☀️ Test successful - checks-actions, checks-azure
Approved by: LukasKalbertodt
Pushing 4cca950 to master...

@bors bors added the merged-by-bors This PR was explicitly merged by bors. label Jul 29, 2020
@bors bors merged commit 4cca950 into rust-lang:master Jul 29, 2020
@tmiasko tmiasko deleted the raw-waker-inline branch July 29, 2020 13:21
@cuviper cuviper added this to the 1.47.0 milestone May 2, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
merged-by-bors This PR was explicitly merged by bors. S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

7 participants