-
Notifications
You must be signed in to change notification settings - Fork 14k
std: split up the thread module
#148765
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
base: main
Are you sure you want to change the base?
std: split up the thread module
#148765
Conversation
|
r? @ChrisDenton rustbot has assigned @ChrisDenton. Use |
This comment has been minimized.
This comment has been minimized.
1db1ae4 to
d9260a8
Compare
|
The Miri subtree was changed cc @rust-lang/miri |
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
e3ebbfb to
0d7d1fa
Compare
|
The job Click to see the possible cause of the failure (guessed by this bot) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Would be good to have some module-level docs for this, the name isn't exactly self-explaining.
|
Hm, I'm going to nominate this for @rust-lang/libs. Not because it particularly needs discussion but just for awareness. If anyone has anything they'd like to change/add about this PR I'd prefer they speak up now then have more churn after this is merged. I've not finished considering it yet but my initial thought is that it seems to have swung a bit too heavily from (almost) everything in one file to (almost) everything in separate files. For example, |
Almost all functionality in
std::threadis currently implemented inthread/mod.rs, resulting in a huge file with more than 2000 lines and multiple, interoperatingunsafesections. This PR splits the file up into multiple different private modules, each implementing mostly independent parts of the functionality. The only remainingunsafeinterplay is that of thelifecycleandscopemodules, thespawn_scopedimplementation relies on the live thread count being updated correctly by thelifecyclemodule.This PR contains no functional changes and only moves code around for the most part, with a few notable exceptions:
with_current_nameis moved to the already existingcurrentmodule and now uses thenamemethod instead of calculating the name from private fields. The old code was just a reimplementation of that method anyway.JoinInnertype used to implement both join handles now has some more methods (is_finished,threadand theAsInner/IntoInnerimplementations) to avoid having to expose private fields and their invariants.spawn_unchecked_(note the underscore) method ofBuilderis now a freestanding function inlifecycle.The rest of the changes are just visibility annotations.
I realise this PR ended up quite large – let me know if there is anyway I can aid the review process.
Edit: I've simplified the diff by adding an intermediate commit that creates all the new files by duplicating
mod.rs. The actual changes in the second commit thus appear to delete the non-relevant parts from the respective file.