Add comment noting that the Arc::clone "not 100% water-proof" applies to thread::scope as well

[CAD97]

This is still a case that's practical to dismiss as impractical (it requires isize::MAX live threads each concurrently in the process of creating a new thread), but it seems prudent to at least acknowledge the potential hole.

[rustbot]

r? @m-ou-se

(rustbot has picked a reviewer for you, use r? to override)

[rustbot]

Hey! It looks like you've submitted a new PR for the library teams!

If this PR contains changes to any rust-lang/rust public library APIs then please comment with @rustbot label +T-libs-api -T-libs to tag it appropriately. If this PR contains changes to any unstable APIs please edit the PR description to add a link to the relevant API Change Proposal or create one if you haven't already. If you're unsure where your change falls no worries, just leave it as is and the reviewer will take a look and make a decision to forward on if necessary.

Examples of T-libs-api changes:

• Stabilizing library features
• Introducing insta-stable changes such as new implementations of existing stable traits on existing stable types
• Introducing new or changing existing unstable library APIs (excluding permanently unstable features / features without a tracking issue)
• Changing public documentation in ways that create new stability guarantees
• Changing observable runtime behavior of library APIs

[m-ou-se]

This is not the same as the situation with Arc::clone(). You can clone and forget an Arc as many times as you like. The situation here is limited by the number of live threads. Each thread has far more than 2 bytes of stack and thread local storage, so it's impossible to have more than usize::MAX / 2 threads that are all concurrently executing the code here (after the increment, before the subsequent decrement).

[JohnCSimon]

@CAD97 Can you please post your status on this PR? It has sat idle for months.

[CAD97]

Not super necessary, will just close.