Skip to content
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

Is Gc pointer equality supported? #71

Open
awestlake87 opened this issue Nov 1, 2021 · 5 comments
Open

Is Gc pointer equality supported? #71

awestlake87 opened this issue Nov 1, 2021 · 5 comments

Comments

@awestlake87
Copy link

I was wondering if there was some sort of equivalent to Arc::ptr_eq for Gc. I've been converting a project with lots of Arc references over to Gc and there are a few places where I want to do an identity check instead of an equality check, but I wasn't able to find anything like this in the docs.

If not, are there any obstacles to adding this check?

@Others
Copy link
Owner

Others commented Nov 1, 2021

I think this should be pretty easy to add--I'll take a look tonight.

You may also be able to work around this with the existing API, by getting the &T references out of the Gc/GcGuard and calling ptr::eq on that

@awestlake87
Copy link
Author

Yeah I had a similar thought. Does something like this look correct to you or is there a chance that a pointer could change between self.get() and other.get()?

pub trait GcIs {
    fn is(&self, other: &Self) -> bool;
}

impl<T> GcIs for Gc<T>
where
    T: Scan,
{
    fn is(&self, other: &Self) -> bool {
        std::ptr::eq(
            self.get().as_ref() as *const T,
            other.get().as_ref() as *const T,
        )
    }
}

@Others
Copy link
Owner

Others commented Nov 1, 2021

That looks correct. It is actually never possible for the pointer returned by .get().deref() to change (if you look at the implementation it's synthesized directly from a static stored pointer)

@awestlake87
Copy link
Author

Ok, awesome! Also, thanks for the quick responses!

I'll just use this trait for now so feel free to close this issue. It'd be great to have something like this in the library eventually, but seems like it's pretty simple to work around.

@Others
Copy link
Owner

Others commented Nov 2, 2021

get is not free, and actually potentially blocking (if collection is happening). So yeah, this definitely needs to be moved internally. See #72

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

No branches or pull requests

2 participants