Change:
Feature gate: [x] Implementation: [ ] : [x] Rename it to : [x] Final comment period (FCP): [x] Stabilization PR: [x] Do we also want to provide a way to access the result of the thread without having to .join() it? See Answer: Maybe, but not a blocker for this feature. [x] Do we also want this in the form of a Future? See Answer: Maybe, but not a blocker for this feature. [x] Name it instead? Answer: Yes.
I think the unresolved questions above can be ideas for future additions, but aren't blockers for this API. merge
Team member has proposed to merge this. The next step is review by the rest of the tagged team members: [x] [ ] [x] [x] [x] [x] No concerns currently listed. Once a majority of reviewers approve (and at most 2 approvals are outstanding), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up! See for info about what commands tagged team members can give me.
I feel like the comment on the PR about (ignoring any naming questions) seemed right: the use case for this seems like "check isrunning and then immediately join, but don't block for any appreciable amount of time". That said, the type signature ( would be annoying to deal with in practice, and it doesn't seem like a good idea to make it work with instead. Given those constraints, this seems like a reasonable API. However, I think I'm going to submit a PR for the documentation, to steer people away from tight-polling on it, and document the intended use case. reviewed
:bell: This is now entering its final comment period, as per the . :bell:
Hm. At the risk of getting philosophical, what does it mean for a thread to be "running", if this would return when the thread is sleeping? And did this get answered in the negative?
I think the question that you are usually asking is "has this thread finished running" rather than "is this thread still running". Perhaps this function could be inverted and renamed to "is_finished"?
While an async method was decided against, I will note Poll uses the idiom or .
+1 for suggestion. Since the intended use case is more or less , it would be clearer to invert the function name:
As suggested above, let's rename to and then FCP that instead. :) cancel
proposal cancelled.
Would it make sense to document that if returns true, it is guaranteed to always return true in subsequent calls (kinda like )? Or is that implied implicitly?
Sounds good.
Let's try again with the new name. Now it's rather than . That removes any ambiguity when the thread is sleeping or blocked (not 'running' (depending on your definition), but still not finished). merge
Team member has proposed to merge this. The next step is review by the rest of the tagged team members: [ ] [x] [x] [ ] [x] [x] No concerns currently listed. Once a majority of reviewers approve (and at most 2 approvals are outstanding), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up! See for info about what commands tagged team members can give me.
:bell: This is now entering its final comment period, as per the . :bell:
The final comment period, with a disposition to merge, as per the , is now complete. As the automated representative of the governance process, I would like to thank the author for their work and everyone else who contributed. This will be merged soon.

Discussion:
/// /// This function does not block. To block while waiting on the thread to finish, /// use [`join`][Self::join]. <del> #[unstable(feature = "thread_is_running", issue = "90470")] </del> <ins> #[stable(feature = "thread_is_running", since = "1.61.0")] </ins> pub fn is_finished(&self) -> bool { Arc::strong_count(&self.0.packet) == 1 }

/// /// This function does not block. To block while waiting on the thread to finish, /// use [`join`][Self::join]. <del> #[unstable(feature = "thread_is_running", issue = "90470")] </del> pub fn is_finished(&self) -> bool { Arc::strong_count(&self.0.packet) == 1 }