Skip to content

Navigation Menu

Sign in
Appearance settings

Search code, repositories, users, issues, pull requests...

Provide feedback

We read every piece of feedback, and take your input very seriously.

Saved searches

Use saved searches to filter your results more quickly

Sign up
Appearance settings

Add fast-path for accessing the current thread id #143069

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

Open
jsimmons wants to merge 1 commit into rust-lang:master
base: master
Choose a base branch
Loading
from jsimmons:current-thread-id-accessor

Conversation

Copy link
Contributor

@jsimmons jsimmons commented Jun 26, 2025

Accessing the thread id is often used in profiling and debugging, as well as some approaches for sound single-threaded access to shared data.

Currently the only way to access the thread id is by first obtaining a handle to the current thread. While this is not exactly slow, it does require an atomic inc-ref and dec-ref operation, as well as the injection of Thread's drop code into the caller.

This publicly exposes the existing fast-path for accessing the current thread id.

Note: I have no idea how these kinds of proposals usually go, but an acp felt overkill for a tiny code change so here we are :)

Accessing the thread id is often used in profiling and debugging, as
well as some approaches for sound single-threaded access to data.
Currently the only way to access the thread id is by first obtaining a
handle to the current thread. While this is not exactly slow, it does
require an atomic inc-ref and dec-ref operation, as well as the
injection of `Thread`'s drop code into the caller.
This publicly exposes the existing fast-path for accessing the current
thread id.
Copy link
Collaborator

rustbot commented Jun 26, 2025

r? @jhpratt

rustbot has assigned @jhpratt.
They will have a look at your PR within the next two weeks and either review your PR or reassign to another reviewer.

Use r? to explicitly pick a reviewer

@rustbot rustbot added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. T-libs Relevant to the library team, which will review and decide on the PR/issue. labels Jun 26, 2025
Copy link
Member

r? libs-api

jhpratt reacted with thumbs up emoji

@rustbot rustbot added the T-libs-api Relevant to the library API team, which will review and decide on the PR/issue. label Jun 26, 2025
@rustbot rustbot assigned m-ou-se and unassigned jhpratt Jun 26, 2025
Copy link
Collaborator

bors commented Aug 7, 2025

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

Copy link
Contributor

tgross35 commented Sep 2, 2025

Note: I have no idea how these kinds of proposals usually go, but an acp felt overkill for a tiny code change so here we are :)

Could you submit one anyway? It's the easiest way to get something on the radar, and it should be trivial.

jsimmons reacted with thumbs up emoji

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Reviewers
No reviews
Labels
S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. T-libs Relevant to the library team, which will review and decide on the PR/issue. T-libs-api Relevant to the library API team, which will review and decide on the PR/issue.
Projects
None yet
Milestone
No milestone
Development

Successfully merging this pull request may close these issues.

AltStyle によって変換されたページ (->オリジナル) /