Stabilize std::{rc,sync}::Weak::{weak_count, strong_count}

[bdonlan]

• Original PR: Implement Weak::{strong_count, weak_count} #56696
• Tracking issue: Tracking issue for Weak::{weak_count, strong_count} #57977

Closes: #57977

Supporting comments:

Although these were added for testing, it is occasionally useful to have a way to probe optimistically for whether a weak pointer has become dangling, without actually taking the overhead of manipulating atomics. Are there any plans to stabilize this?

Originally posted by @bdonlan in #57977 (comment)

Having this stabilized would help. Currently, the only way to check if a weak pointer has become dangling is to call upgrade, which is by far expensive.

Originally posted by @glebpom in #57977 (comment)

Not sure if stabilizing these warrants a full RFC, so throwing this out here as a start for now.

Note: per CONTRIBUTING.md, I ran the tidy checks, but they seem to be failing on unchanged files (primarily in src/stdsimd).

[rust-highfive]

Thanks for the pull request, and welcome! The Rust team is excited to review your changes, and you should hear from @rkruppe (or someone else) soon.

If any changes to this PR are deemed necessary, please add them as extra commits. This ensures that the reviewer can see what has changed since they last reviewed the code. Due to the way GitHub handles out-of-date commits, this should also make it reasonably obvious what issues have or haven't been addressed. Large or tricky changes may require several passes of review and changes.

Please see the contribution instructions for more information.

[hanna-kruppe]

The diff looks good to me, but stabilizing requires a @rust-lang/libs FCP and that hasn't happened yet on the tracking issue. I don't think the bot will listen to me, so let's wait for a libs team member to show up.

[alexcrichton]

@rfcbot fcp merge

Looks like this is stabilizing:

mod rc {
    impl Weak<T> {
        pub fn strong_count(&self) -> usize;
        pub fn weak_count(&self) -> Option<usize>;
    }
}

mod sync {
    impl Weak<T> {
        pub fn strong_count(&self) -> usize;
        pub fn weak_count(&self) -> Option<usize>;
    }
}

where weak_count returns None for Weak::new. There's also some notes for Arc about how the value read can be racy

[rfcbot]

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

• @Amanieu
• @Kimundi
• @KodrAus
• @SimonSapin
• @alexcrichton
• @dtolnay
• @sfackler
• @withoutboats

Concerns:

• is this the API we want? resolved by Stabilize std::{rc,sync}::Weak::{weak_count, strong_count} #65778 (comment)
• return 0 or the true weak count when all strong references have been dropped? resolved by Stabilize std::{rc,sync}::Weak::{weak_count, strong_count} #65778 (comment)

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.

[sfackler]

I assume this may have already been discussed, but why would a Weak created via new not just return 1 from weak_count?

[alexcrichton]

I believe it's "technically a lie" because you can clone a Weak::new but you can't ever know how many clones were created

[sfackler]

Ah right, that makes sense.

[KodrAus]

@rfcbot concern is this the API we want?

The motivation for this seems to be entirely focused around cheaply determining if Weak::upgrade could possibly return Some, and since sync::Weak::weak_count behaves oddly should we just expose some kind of fn is_dangling() -> bool method on Weak instead (something like @stepancheg suggested) that doesn't give the illusion of offering any more information?

If we do want this API as-is then I think the docs need a little more attention. sync::Weak::new().weak_count() suggests you'll get Some(0), but you actually get None, like rc::Weak::new().weak_count(). sync::Weak should probably also carry the same safety notes as sync::Arc.

[jonas-schievink]

I agree that having an additional is_dangling or has_strong method makes sense, but I think these methods are still useful by themselves (eg. to write tests where a specific number of references is expected).

[bdonlan]

Perhaps an is_upgradable() function would be useful? Since we don't actually care about the count, we might be able to get away with relaxed ordering when reading the strong count in this case as well.

[KodrAus]

@jonas-schievink Do you have any examples of such a datastructure that needs to assert on the count through a Weak that isn't just trying to determine whether or not it's upgradable? I did a quick scan on GitHub and didn't turn up much, but there's lots of Rust that isn't publicly available on GitHub!

If not, I think I'd err towards stabilizing the semantically tighter is_ugradable() API.

[jonas-schievink]

My original use case for adding these methods was for unit tests in https://github.com/jonas-schievink/rcgc, which would've benefitted from the exact counts

[KodrAus]

@rfcbot resolved is this the API we want?

Ok, thanks for the follow-up @jonas-schievink! Modulo docs I'll call this concern resolved and not block stabilization.

[stepancheg]

One of the problems with the current API is that it exposes certain internals which we might not keep forever.

For example this program:

    let a = Rc::new(1);
    let c = Rc::downgrade(&a);
    drop(a);
    let d = c.clone();
    println!("{:?}", d.weak_count());

currently prints Some(2), and not None.

However, value is dropped, weak will never become strong. In particular, in clone it might be more convenient to create empty Weak instead of incremeting a refcounter when strong_count == 0 (to potentially save memory).

However, when we intentionally specify that weak_count returns Option<usize> instead of usize, we make this possible change harder in the future.

If we really need to expose counters (instead of is_upgradable), how about returning usize in weak_count instead of Option<usize>?

[bdonlan]

An option would be to specify that weak_count eventually will return zero once the strong count drops to zero (implementation-wise, we would perform a relaxed read on the strong count, and force the weak count to zero if the strong count is zero). This should provide consistent behavior in unit tests that have sufficient memory barriers to have reproducible results in the first place.

[bdonlan]

@stepancheg any thoughts on the suggestion above - whether weak_count should return zero or the true weak count for the case where all strong references have been dropped?

[stepancheg]

@bdonlan Good question. IMHO returning zero from weak count when strong is zero would be consistent. For the same reason: allow future optimizations without breaking compatibility.

[bdonlan]

I'd be happy to update the semantics of weak_count to reflect that if it's desirable - not sure what the process would be for this though. Should I open a separate PR for that, or just add a commit here? Or do we need more consensus from the T-libs team members first?

[rfcbot]

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

[bors]

💔 Test failed - checks-azure

[dtolnay]

Looks like chocolatey is flaking again.

Chocolatey v0.10.15
Installing the following packages:
msys2
By installing you accept licenses for the packages.
msys2 not installed. An error occurred during installation:
 The remote server returned an error: (503) Server Unavailable. Service Unavailable
msys2 package files install completed. Performing other installation steps.
The install of msys2 was NOT successful.
msys2 not installed. An error occurred during installation:
 The remote server returned an error: (503) Server Unavailable. Service Unavailable

Chocolatey installed 0/1 packages. 1 packages failed.
 See the log for details (C:\ProgramData\chocolatey\logs\chocolatey.log).

Failures
 - msys2 (exited 1) - msys2 not installed. An error occurred during installation:
 The remote server returned an error: (503) Server Unavailable. Service Unavailable 

@bors retry

[bors]

⌛ Testing commit 9778e03 with merge da8b4f5d292f705c91fa120a8649a9f545518383...

[rust-highfive]

Your PR failed (pretty log, raw log). Through arcane magic we have determined that the following fragments from the build log may contain information about the problem.

Click to expand the log.

2019-12-16T07:10:16.3438678Z do so (now or later) by using -b with the checkout command again. Example:
2019-12-16T07:10:16.3439975Z 
2019-12-16T07:10:16.3440137Z   git checkout -b <new-branch-name>
2019-12-16T07:10:16.3440218Z 
2019-12-16T07:10:16.3440302Z HEAD is now at da8b4f5d2 Auto merge of #65778 - bdonlan:stable_weak_count, r=dtolnay
2019-12-16T07:10:16.3782741Z ##[section]Starting: Setup environment
2019-12-16T07:10:16.3871125Z ==============================================================================
2019-12-16T07:10:16.3871197Z Task         : Bash
2019-12-16T07:10:16.3871272Z Description  : Run a Bash script on macOS, Linux, or Windows
---
2019-12-16T07:10:17.6864198Z 
2019-12-16T07:10:17.6864317Z 
2019-12-16T07:10:17.6864533Z * Original PR: #56696
2019-12-16T07:10:17.6864724Z * Tracking issue: #57977
2019-12-16T07:10:17.6864960Z > Although these were added for testing, it is occasionally useful to have a way to probe optimistically for whether a weak pointer has become dangling, without actually taking the overhead of manipulating atomics. Are there any plans to stabilize this?
2019-12-16T07:10:17.6867890Z > Having this stabilized would help. Currently, the only way to check if a weak pointer has become dangling is to call `upgrade`, which is by far expensive.
2019-12-16T07:10:17.6868114Z AGENT_DISABLELOGPLUGIN_TESTFILEPUBLISHERPLUGIN=true
2019-12-16T07:10:17.6869626Z AGENT_DISABLELOGPLUGIN_TESTRESULTLOGPLUGIN=true
2019-12-16T07:10:17.6869717Z AGENT_HOMEDIRECTORY=C:\agents\2.163.1
2019-12-16T07:10:17.6869771Z AGENT_ID=514
---
2019-12-16T07:10:17.6874540Z BUILD_SOURCEBRANCHNAME=auto
2019-12-16T07:10:17.6874593Z BUILD_SOURCESDIRECTORY=D:\a\1\s
2019-12-16T07:10:17.6874698Z BUILD_SOURCEVERSION=da8b4f5d292f705c91fa120a8649a9f545518383
2019-12-16T07:10:17.6874766Z BUILD_SOURCEVERSIONAUTHOR=bors
2019-12-16T07:10:17.6874857Z BUILD_SOURCEVERSIONMESSAGE=Auto merge of #65778 - bdonlan:stable_weak_count, r=dtolnay
2019-12-16T07:10:17.6874992Z CI_JOB_NAME=i686-mingw-2
2019-12-16T07:10:17.6875069Z COBERTURA_HOME=C:\cobertura-2.1.1
2019-12-16T07:10:17.6875131Z COMMONPROGRAMFILES=C:\Program Files\Common Files
2019-12-16T07:10:17.6875211Z COMMON_TESTRESULTSDIRECTORY=D:\a\1\TestResults
---
2019-12-16T07:10:17.6878993Z MonAgentClientLocation=C:\Packages\Plugins\Microsoft.Azure.Geneva.GenevaMonitoring\2.15.0.1\Monitoring\Agent
2019-12-16T07:10:17.6879081Z NPM_CONFIG_CACHE=C:\npm\cache
2019-12-16T07:10:17.6879135Z NPM_CONFIG_PREFIX=C:\npm\prefix
2019-12-16T07:10:17.6879206Z NUMBER_OF_PROCESSORS=2
2019-12-16T07:10:17.6879277Z Not sure if stabilizing these warrants a full RFC, so throwing this out here as a start for now.
2019-12-16T07:10:17.6879389Z Note: per CONTRIBUTING.md, I ran the tidy checks, but they seem to be failing on unchanged files (primarily in `src/stdsimd`).
2019-12-16T07:10:17.6880119Z PATH=/mingw64/bin:/usr/bin:/c/Users/VssAdministrator/bin:/c/agents/2.163.1/externals/git/cmd:/c/hostedtoolcache/windows/Python/3.6.8/x64:/c/hostedtoolcache/windows/Python/3.6.8/x64/Scripts:/c/Program Files/Mercurial:/c/ProgramData/kind:/c/vcpkg:/c/cf-cli:/c/Program Files (x86)/NSIS:/c/Program Files/Mercurial:/c/Program Files/Boost/1.69.0:/c/Program Files/dotnet:/c/mysql-5.7.21-winx64/bin:/c/Program Files/Java/zulu-8-azure-jdk_8.40.0.25-8.0.222-win_x64/bin:/c/npm/prefix:/c/Program Files (x86)/sbt/bin:/c/Rust/.cargo/bin:/c/hostedtoolcache/windows/Ruby/2.5.5/x64/bin:/c/Go1.12.7/bin:/bin:/usr/bin:/mingw64/bin:/c/hostedtoolcache/windows/Python/3.6.8/x64/Scripts:/c/hostedtoolcache/windows/Python/3.6.8/x64:/c/Program Files (x86)/Microsoft SDKs/Azure/CLI2/wbin:/c/Program Files/Microsoft MPI/Bin:/c/windows/system32:/c/windows:/c/windows/System32/Wbem:/c/windows/System32/WindowsPowerShell/v1.0:/c/ProgramData/Chocolatey/bin:/c/Program Files/Docker:/c/Program Files/PowerShell/6:/c/Program Files/dotnet:/c/Program Files/Microsoft SQL Server/130/Tools/Binn:/c/Program Files (x86)/Microsoft SQL Server/110/DTS/Binn:/c/Program Files (x86)/Microsoft SQL Server/120/DTS/Binn:/c/Program Files (x86)/Microsoft SQL Server/130/DTS/Binn:/c/Program Files (x86)/Microsoft SQL Server/140/DTS/Binn:/c/Program Files (x86)/Microsoft SQL Server/150/DTS/Binn:/c/Program Files (x86)/Windows Kits/10/Windows Performance Toolkit:/c/Program Files/Microsoft Service Fabric/bin/Fabric/Fabric.Code:/c/Program Files/Microsoft SDKs/Service Fabric/Tools/ServiceFabricLocalClusterManager:/cmd:/mingw64/bin:/usr/bin:/c/tools/php:/c/Program Files (x86)/sbt/bin:/c/Program Files (x86)/Subversion/bin:/c/Program Files/nodejs:/c/ProgramData/chocolatey/lib/maven/apache-maven-3.6.2/bin:/c/Program Files/CMake/bin:/c/Strawberry/c/bin:/c/Strawberry/perl/site/bin:/c/Strawberry/perl/bin:/c/Program Files/OpenSSL/bin:/c/Users/VssAdministrator/.dotnet/tools:/c/Program Files 
2019-12-16T07:10:17.6880701Z PATHEXT=.COM;.EXE;.BAT;.CMD;.VBS;.VBE;.JS;.JSE;.WSF;.WSH;.MSC
2019-12-16T07:10:17.6880764Z PHPROOT=c:\tools\php
2019-12-16T07:10:17.6880839Z PIPELINE_WORKSPACE=D:\a\1
---
2019-12-16T07:10:17.6886900Z VSTS_PROCESS_LOOKUP_ID=vsts_663d959e-540c-4850-b926-578053181993
2019-12-16T07:10:17.6886960Z WINDIR=C:\windows
2019-12-16T07:10:17.6887030Z WIX=C:\Program Files (x86)\WiX Toolset v3.11\
2019-12-16T07:10:17.6887085Z _=/usr/bin/printenv
2019-12-16T07:10:17.6887175Z _Originally posted by @bdonlan in https://github.com/rust-lang/rust/issues/57977#issuecomment-516970921_
2019-12-16T07:10:17.6887286Z _Originally posted by @glebpom in https://github.com/rust-lang/rust/issues/57977#issuecomment-526934709_
2019-12-16T07:10:17.6887440Z 
2019-12-16T07:10:17.6887489Z disk usage:
2019-12-16T07:10:17.7552991Z Filesystem            Size  Used Avail Use% Mounted on
2019-12-16T07:10:17.7559923Z C:/Program Files/Git  256G  143G  114G  56% /
---
2019-12-16T07:10:29.5534963Z Chocolatey v0.10.15
2019-12-16T07:11:29.4804858Z Installing the following packages:
2019-12-16T07:11:29.4807866Z msys2
2019-12-16T07:11:29.4811593Z By installing you accept licenses for the packages.
2019-12-16T07:13:10.3014635Z Error retrieving packages from source 'https://chocolatey.org/api/v2/':
2019-12-16T07:13:10.3015430Z  Could not connect to the feed specified at 'https://chocolatey.org/api/v2/'. Please verify that the package source (located in the Package Manager Settings) is valid and ensure your network connectivity.
2019-12-16T07:13:10.3026681Z msys2 not installed. The package was not found with the source(s) listed.
2019-12-16T07:13:10.3026885Z  Source(s): 'https://chocolatey.org/api/v2/'
2019-12-16T07:13:10.3027034Z  NOTE: When you specify explicit sources, it overrides default sources.
2019-12-16T07:13:10.3027153Z If the package version is a prerelease and you didn't specify `--pre`,
2019-12-16T07:13:10.3027324Z Please see https://chocolatey.org/docs/troubleshooting for more 
2019-12-16T07:13:10.3027383Z  assistance.
2019-12-16T07:13:10.3112949Z 
2019-12-16T07:13:10.3113176Z Chocolatey installed 0/1 packages. 1 packages failed.
2019-12-16T07:13:10.3113176Z Chocolatey installed 0/1 packages. 1 packages failed.
2019-12-16T07:13:10.3113255Z  See the log for details (C:\ProgramData\chocolatey\logs\chocolatey.log).
2019-12-16T07:13:10.3116651Z 
2019-12-16T07:13:10.3120183Z Failures
2019-12-16T07:13:10.3126051Z  - msys2 - msys2 not installed. The package was not found with the source(s) listed.
2019-12-16T07:13:10.3126227Z  Source(s): 'https://chocolatey.org/api/v2/'
2019-12-16T07:13:10.3126297Z  NOTE: When you specify explicit sources, it overrides default sources.
2019-12-16T07:13:10.3126437Z If the package version is a prerelease and you didn't specify `--pre`,
2019-12-16T07:13:10.3126620Z Please see https://chocolatey.org/docs/troubleshooting for more 
2019-12-16T07:13:10.3126719Z  assistance.
2019-12-16T07:13:10.3135729Z 
2019-12-16T07:13:10.3135862Z Enjoy using Chocolatey? Explore more amazing features to take your
2019-12-16T07:13:10.3135862Z Enjoy using Chocolatey? Explore more amazing features to take your
2019-12-16T07:13:10.3135968Z experience to the next level at
2019-12-16T07:13:10.3136203Z  https://chocolatey.org/compare
2019-12-16T07:13:10.6763808Z 
2019-12-16T07:13:10.6843432Z ##[error]Bash exited with code '1'.
2019-12-16T07:13:10.6990366Z ##[section]Starting: Checkout
2019-12-16T07:13:10.7079109Z ==============================================================================
2019-12-16T07:13:10.7079190Z Task         : Get sources
2019-12-16T07:13:10.7079258Z Description  : Get sources from a repository. Supports Git, TfsVC, and SVN repositories.

I'm a bot! I can only do what humans tell me to, so if this was not helpful or you have suggestions for improvements, please ping or otherwise contact @TimNN. (Feature Requests)

[bors]

💔 Test failed - checks-azure

[Centril]

@bors retry