Re: [PATCH v2 1/2] rust: sync: add `ArcBorrow::from_raw`

From: Alice Ryhl
Date: Mon Mar 11 2024 - 04:58:35 EST


On Sat, Mar 9, 2024 at 1:56 PM Benno Lossin <benno.lossin@xxxxxxxxx> wrote:
> > + /// Creates an [`ArcBorrow`] to an [`Arc`] that has previously been deconstructed with
> > + /// [`Arc::into_raw`].
> > + ///
> > + /// # Safety
> > + ///
> > + /// * The provided pointer must originate from a call to [`Arc::into_raw`].
> > + /// * For the duration of the lifetime annotated on this `ArcBorrow`, the reference count must
> > + /// not hit zero.
> > + /// * For the duration of the lifetime annotated on this `ArcBorrow`, there must not be a
> > + /// [`UniqueArc`] reference to this value.
>
> I am a bit confused, this feels to me like it should be guaranteed by
> `UniqueArc` and not by this function. Currently there is not even a way
> of getting a `*const T` from a `UniqueArc`.
> So I think we can remove this requirement and instead have the
> requirement for creating `UniqueArc` that not only the refcount is
> exactly 1, but also that no `ArcBorrow` exists.

If you combine this with `into_unique_or_drop` that is introduced in
the next patch of this series, then you could perform these
operations:

* Arc::into_raw
* ArcBorrow::from_raw
* Arc::from_raw
* Arc::into_unique_or_drop
* And then use the ArcBorrow

If we drop the final safety requirement from `ArcBorrow::from_raw`,
then the above would be allowed. The refcount does not hit zero at any
point during these operations. The only unsafe functions are
Arc::into_raw, Arc::from_raw, and ArcBorrow::from_raw, so this safety
requirement must go on one of them. It seems to me that, out of these,
ArcBorrow::from_raw is the most appropriate choice.

Thoughts?

Alice