Skip to content

Document panic from thread::current #107216

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.

Sign up for GitHub

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

Closed
wants to merge 1 commit into from
Closed

Document panic from thread::current #107216

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
7 changes: 7 additions & 0 deletions library/std/src/thread/mod.rs
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -717,6 +717,13 @@ where

/// Gets a handle to the thread that invokes it.
///
/// # Panics
///
/// Panics if called beyond the end of `main`, when the Rust standard library's
Copy link
Member

Choose a reason for hiding this comment

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

Why not just remove the guarantee?

Suggested change
/// Panics if called beyond the end of `main`, when the Rust standard library's
/// This may panic if called beyond the end of `main`, if the Rust standard library's

/// thread state has been torn down. For example, use of `libc::atexit` on some
/// platforms can hit this. In general much of the standard library is not okay
/// to use before or after `main`.
Comment on lines +724 to +725
Copy link
Member

Choose a reason for hiding this comment

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

This isn't really the right place to mention this, as ChrisDenton said it would be good to have some module documentation (perhaps on the std top level module) explaining this and then linking to that section.

Copy link
Member Author

Choose a reason for hiding this comment

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

I'll look for a spot. Is it fair to say 100% of libcore is fine to use before/after main, but the default assumption for libstd stuff like std::thread and std::io is it's UB to use before/after main, with the observable behavior being indistinguishable from a panic in the best case? How about liballoc?

Copy link
Member

Choose a reason for hiding this comment

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

Some core and alloc functions could get poisoned through hooks like the global allocator or panic hooks.

I'll look for a spot.

Since this affects multiple modules maybe the top level?

the default assumption for libstd stuff like std::thread and std::io is it's UB to use before/after main, with the observable behavior being indistinguishable from a panic in the best case

That's a tough one, I guess it's true that there might be UB lurking somewhere but feels a bit like a "known to the state of california to cause cancer" statement.

Copy link
Member

Choose a reason for hiding this comment

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

Technically there are some functions that are probably UB on Windows. In particular when you're running before main on Windows, the loader lock is likely held, and we may call into functions that are UB if the loader lock is helt (but in practice these are likely to be just a deadlock).

We historically have taken measures to reduce the damage of UB (usually by mitigating it into a "does not work" state) from doing stuff to std before main, as people do do it. I would certainly like to discourage it, though.

Copy link
Member

Choose a reason for hiding this comment

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

with the observable behavior being indistinguishable from a panic in the best case

The best case is that it just works. But that depends on the platform and operation.

///
/// # Examples
///
/// Getting a handle to the current thread with `thread::current()`:
Expand Down