Tracking Issue for JoinHandle::is_finished

[m-ou-se]

Feature gate: #![feature(thread_is_running)]

Public API

impl<T> JoinHandle<T> {
    pub fn is_finshed(&self) -> bool;
}

Steps / History

• Implementation: Add JoinHandle::is_running. #90439
• First Final comment period (FCP): Tracking Issue for JoinHandle::is_finished #90470 (comment)
• Rename it to is_finished: Rename JoinHandle::is_running to is_finished. #94549
• Final comment period (FCP): Tracking Issue for JoinHandle::is_finished #90470 (comment)
• Stabilization PR: Stabilize thread::is_finished #95130

Unresolved Questions

• Do we also want to provide a way to access the result of the thread without having to .join() it? See Add JoinHandle::is_running. #90439 (comment)
  • Answer: Maybe, but not a blocker for this feature.
• Do we also want this in the form of a Future? See Add JoinHandle::is_running. #90439 (comment)
  • Answer: Maybe, but not a blocker for this feature.
• Name it is_finished instead?
  • Answer: Yes.

[m-ou-se]

I think the unresolved questions above can be ideas for future additions, but aren't blockers for this API.

@rfcbot merge

[rfcbot]

Team member @m-ou-se has proposed to merge this. The next step is review by the rest of the tagged team members:

• @Amanieu
• @BurntSushi
• @dtolnay
• @joshtriplett
• @m-ou-se
• @yaahc

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 this document for info about what commands tagged team members can give me.

[joshtriplett]

I feel like the comment on the PR about try_join (ignoring any naming questions) seemed right: the use case for this seems like "check is_running and then immediately join, but don't block for any appreciable amount of time".

That said, the type signature (fn try_join(self) -> Result<..., Self> would be annoying to deal with in practice, and it doesn't seem like a good idea to make it work with &self 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.

@rfcbot reviewed

[joshtriplett]

#94033

[rfcbot]

🔔 This is now entering its final comment period, as per the review above. 🔔

[workingjubilee]

Hm. At the risk of getting philosophical, what does it mean for a thread to be "running", if this would return true when the thread is sleeping?

And did this get answered in the negative?

Wouldn't detaching the thread after pulling out the result work on platforms that don't have a non-blocking join?

[Amanieu]

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"?

[workingjubilee]

While an async method was decided against, I will note Poll uses the idiom is_ready or is_pending.

[Julian-Wollersberger]

+1 for @Amanieu's suggestion.
Since the intended use case is more or less if !is_running() { join() }, it would be clearer to invert the function name: if is_finished() { join() }

[m-ou-se]

As suggested above, let's rename to is_finished and then FCP that instead. :)

@rfcbot cancel

[rfcbot]

@m-ou-se proposal cancelled.

[madsmtm]

Would it make sense to document that if is_finished returns true, it is guaranteed to always return true in subsequent calls (kinda like FusedIterator)? Or is that implied implicitly?

[m-ou-se]

Would it make sense to document that if is_finished returns true, it is guaranteed to always return true in subsequent calls (kinda like FusedIterator)?

Sounds good.

[m-ou-se]

Let's try again with the new name. Now it's is_finished() rather than is_running(). That removes any ambiguity when the thread is sleeping or blocked (not 'running' (depending on your definition), but still not finished).

@rfcbot merge

[rfcbot]

Team member @m-ou-se has proposed to merge this. The next step is review by the rest of the tagged team members:

• @Amanieu
• @BurntSushi
• @dtolnay
• @joshtriplett
• @m-ou-se
• @yaahc

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 this document for info about what commands tagged team members can give me.

[rfcbot]

🔔 This is now entering its final comment period, as per the review above. 🔔

[rfcbot]

The final comment period, with a disposition to merge, as per the review above, 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.