[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20230925150425.1963183-1-aliceryhl@google.com>
Date: Mon, 25 Sep 2023 15:04:25 +0000
From: Alice Ryhl <aliceryhl@...gle.com>
To: benno.lossin@...ton.me
Cc: a.hindborg@...sung.com, alex.gaynor@...il.com,
aliceryhl@...gle.com, bjorn3_gh@...tonmail.com,
boqun.feng@...il.com, gary@...yguo.net,
linux-kernel@...r.kernel.org, ojeda@...nel.org,
rust-for-linux@...r.kernel.org, walmeida@...rosoft.com,
wedsonaf@...il.com
Subject: Re: [PATCH v2 2/2] rust: arc: remove `ArcBorrow` in favour of `WithRef`
>> I'm concerned about this change, because an `&WithRef<T>` only has
>> immutable permissions for the allocation. No pointer derived from it
>> may be used to modify the value in the Arc, however, the drop
>> implementation of Arc will do exactly that.
>
> That is indeed a problem. We could put the value in an `UnsafeCell`, but
> that would lose us niche optimizations and probably also other optimizations.
This is an option. Niche optimizations don't matter for `WithRef` since
it's never directly wrapped with `Option`.
> > It also means that we
> > can't convert an Arc with refcount 1 into a UniqueArc.
>
> I think you still can, since to do that you would consume the `Arc<T>` by
> value, thus guaranteeing that no references (and thus no `&WithRef<T>`) exist.
> So I think this would still be fine.
The problem is that if you have an `&WithRef<T>` and use that to create
an `Arc<T>`, then the raw pointer in the `Arc<T>` was created from an
immutable reference, so the same restrictions apply to that `Arc<T>`.
And if you convert it into an `UniqueArc<T>`, then the same restrictions
also apply to the `UniqueArc<T>` because it's raw pointer was derived
from the immutable reference.
Alice
Powered by blists - more mailing lists