Skip to content

add task-local reference counted smart pointers #6241

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 1 commit into from
May 7, 2013
Merged

add task-local reference counted smart pointers #6241

merged 1 commit into from
May 7, 2013

Conversation

thestinger
Copy link
Contributor

To provide a reference counted pointer type with deterministic
destruction once managed boxes are switched over to a garbage
collector. Unlike managed boxes, these can be moved instead of just
copied/cloned which is helpful for avoiding reference counts.

Needs #5601 to be fixed in order for safety to be provided without the current ugly workaround of making the pointers contain Option<@()> and Option<@mut ()> (which are just set to None).

@brson: r?

@brson
Copy link
Contributor

brson commented May 5, 2013

Awesome. This is an important topic and I want to think about it a bit before r+ing, maybe get the ok from @pcwalton who has opinions on this subject.

We're going to need something like this in the runtime so once it does not depend on the local heap we may end up moving it to core::unstable and reexporting it, or maybe just making it part of core.

I've been creating a lot of these container types with borrow_* methods lately and feel like this needs to be extracted out into a set of traits and types for containers that obey borrow semantics. Not that we need that implemented for this pull request.

🌞

@thestinger
Copy link
Contributor Author

@nikomatsakis and I came to the conclusion that the restriction of only containing Owned types is stricter than it has to be to prevent cycles.

An Rc can only be cyclic if it contains a non-Const type like @mut since the self-reference has to be added after construction.

An RcMut is neither Owned or Const, so only one of those bounds is needed to prevent cycles.

Therefore we can have two constructors (one for T: Owned, one for T: Const) and keep the guarantee of never having cycles. This will make Rc usable for a recursive persistent data structure.

@thestinger
Copy link
Contributor Author

Once #6251 lands I can remove the use of @ from these.

@brson
Copy link
Contributor

brson commented May 6, 2013

This looks fine to me, but I'd like someone else to sign off on it and #[non_owned].

FWIW this code could avoid using the init intrinsics by allocating with ~ instead of malloc. When you allocate the pointer you just move T into the ~ then cast the ~ to *c_void. When destroying just cast the *c_void back to ~ and Rust takes care of the rest.

@thestinger
Copy link
Contributor Author

@brson: I think using ~ is required anyway if I'm going to allow Const objects that aren't Owned. It needs to use the local heap if you put @ inside one of these. It's a shame to end up with two sets of metadata but at least it will be gone for non-managed values eventually.

To provide a reference counted pointer type with deterministic
destruction once managed boxes are switched over to a garbage
collector. Unlike managed boxes, these can be moved instead of just
copied/cloned which is helpful for avoiding reference counts.
bors added a commit that referenced this pull request May 7, 2013
To provide a reference counted pointer type with deterministic
destruction once managed boxes are switched over to a garbage
collector. Unlike managed boxes, these can be moved instead of just
copied/cloned which is helpful for avoiding reference counts.

Needs #5601 to be fixed in order for safety to be provided without the current ugly workaround of making the pointers contain `Option<@()>` and `Option<@mut ()>` (which are just set to `None`).

@brson: r?
@bors bors closed this May 7, 2013
@bors bors merged commit 3d526d1 into rust-lang:incoming May 7, 2013
flip1995 pushed a commit to flip1995/rust that referenced this pull request Oct 20, 2022
update Applicability of `rc_buffer` lint from `MachineApplicable` to `Unspecified`

`Unspecified`

This changes `rc_buffer` from MachineApplicable to Unspecified

```
changelog: change [`rc_buffer`] to Unspecified.
```

fixes rust-lang#6241

---

changelog: change [`rc_buffer`] to Unspecified.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants