Rc, send all clones?

Out of curiousity: If T: Send and some magic guarantees that all clones of Rc<T> are send to another thread in one atomic transaction, would the dragons stay in my nose?

They would stay in your nose, but it’s risky from a maintenance perspective. I’m assuming you’re stuck with having Rcs and not the underlying value? That is, the obvious and natural approach would be to send the T value to the thread, and then create Rcs there.

1 Like

Fully agree with respect to the maintenance. This question came really just out of curiousity.

You might be able to get away with it, but all it takes is for one person to stash away a copy of your Rc<T> somewhere and the dragons will all come flying out again.

You’d need to have very good reasoning for me to even consider it in code review.

It would probably work right now, but that’s by no means guaranteed. For example, Rc could choose to keep reference counts in a thread-local hashmap, at which point everything would blow up.

(That implementation would be pretty bad for perf, so almost certainly wouldn’t happen, but it would meet all the guarantees that Rc provides, and could offer some nice things like no-realloc Box <-> Rc conversions.)

Like I said before, this question came up out of curiousity while reading the source code of Rc, Arc and friends.

Of course there is no such “magic guarantee” which I assumed in my original question. Any such attempt to try this in a real project would be totally unsafe. Furthermore, there is no need to do this because the same effect can be obtained in a safe way.

Incidentally, saw the following PR into rustc today: https://github.com/rust-lang/rust/pull/50549