Tracking issue for Arc/Rc extras

[alexcrichton]

This is a tracking issue for the arc_counts, rc_counts, and rc_would_unwrap features. The counting functions have been around for awhile but would_unwrap was added recently.

cc #27718, more discussion there.

[timcharper]

@alexcrichton I think there may be a good use for strong_count in detecting un-fulfillable promises. Although, I am struggling with it, because most cases I think of are racy.

If you try and get the value of a promise synchronously, and there is only one instance of the promise, then you can fail the promise ahead of time because either nobody is listening, or nobody is fulfilling.

See the discussion here: viperscape/rust-promise#3

[timcharper]

The more I think about this, I think the more your point about hard_count being finicky is corroborated. This case is racey and complex. It'd be better / more deterministic to just have the promise register itself to listen for a thread panic, and just fail if it does.

[alexcrichton]

@timcharper yeah in general the methods on Arc are inherently racy, but there's a point that can be made where there's external synchronization in play so the raciness doesn't actually happen in some specific scenarios (in which case these may be desired)

[jethrogb]

I rewrote my usecase for strong_count to work with Option<Arc<_>> and Arc::try_unwrap so I no longer actually need this.

[shahn]

If this gets stabilized, these APIs should get added to the respective Weak as well I'm thinking

[johalun]

What is planned for arc_counts? I would like to use it because I need to do ffi call to c library when the last Arc pointer is dropped but don't wanna start using it if it might disappear soon.. Maybe a different approach would be to do the call when the inner structure is being dropped, that would definitely be when the last pointer is dropped because is has only one owner..

[ticki]

May I ask: What is the point of Arc and Rc keeping the weak reference count? They should be irrelevant to them.

[Gankra]

@ticki I don't understand the question. Rc/Weak are dual types that have different interpretations of the same memory. Individual Rc/Weaks do not store a count. Rather, they all share RcBoxes to coordinate these counts.

[ticki]

I don't understand the question. Rc/Weak are dual types that have different interpretations of the same memory. Individual Rc/Weaks do not store a count. Rather, they all share RcBoxes to coordinate these counts.

Yeah, that's right. They're just pointers to the actual data plus a weak and a strong reference count. What I ask is: why do they keep track of the weak reference count? For example, C++ and Obj-C do not count the weak references.

[timcharper]

If I were to venture a guess, strong reference counts are used to know when the ARC contained data should be freed, weak reference counts are used to know when the ARC container should be freed.

I'm surprised to learn that C++ / Obj-C don't do this (at least, under the hood). What data structure does the weak reference query to learn if the memory has been freed?

[ticki]

In fact, I was wrong about C++ shared_ptr:

The control block is a dynamically-allocated object that holds:

• either a pointer to the managed object or the managed object itself;
• the deleter (type-erased);
• The allocator (type-erased);
• the number of shared_ptrs that own the managed object;
• the number of weak_ptrs that refer to the managed object.

(emphasis mine)

Source: http://en.cppreference.com/w/cpp/memory/shared_ptr

[Gankra]

Obj-C strategy is explained here: https://mikeash.com/pyblog/friday-qa-2010-07-16-zeroing-weak-references-in-objective-c.html

Basically: every class instance has a set of "locations of weak pointers". When its strong count hits 0, it traverses the set, nulls out those pointers, and then frees all of its allocations.

This can't be implemented in Rust, because it requires weak pointers to have significant locations in memory. Would necessitate overloading move (never gonna happen), or runtime support (unlikely to happen).

That said, @pnkfelix has been working on the notion of stack introspection hooks for GC's, which could maybe accommodate this use-case..? Not something we would retrofit Arc/Rc to use, but something someone could do with their own custom types.

[jminer]

Does it look like either rc_counts or rc_would_unwrap will be stablilized? I'm wrapping a C library and have a place I'd like to test strong_count == 1 or use would_unwrap, and similarly to @SimonSapin's usecase, I can't use try_unwrap. The check is in drop of a wrapper struct, where I only have &mut self (I need to free some memory when the last reference is dropped). I can probably add another struct to wrap the contents of the Rc, but the code won't be as clear.