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

Safe way to use crossbeam-epoch? #960

Open
Speak2Erase opened this issue Feb 10, 2023 · 0 comments
Open

Safe way to use crossbeam-epoch? #960

Speak2Erase opened this issue Feb 10, 2023 · 0 comments

Comments

@Speak2Erase
Copy link

I'm currently writing up a 2D renderer using wgpu and it makes heavy use of Arc and Mutex at the moment, which is fine.
However, just to get a proof of concept working, I had to use transmute to avoid a problem with lifetimes:

    // Self here is a Mutex, which is in practice always locked behind a Arc
    fn draw(&self, render_pass: &mut wgpu::RenderPass) {
        let internal = self.lock();

        if let Some(ref bitmap) = internal.bitmap {
            ShaderManager::sprite().bind(render_pass);

            render_pass.set_bind_group(0, unsafe { std::mem::transmute(bitmap.bind_group()) }, &[]);

            render_pass.draw_indexed(0..9, 0, 0..1);
        }
    }

The issue here is that bitmap (and bitmap.bind_group) is tied to the lifetime of a MutexGaurd and wgpu::RenderPass wants it to live for as long as it does.
Having done some testing it's fine, but there is a possibility of the Arc that contains the Mutex being dropped leading to a use after free.

crossbeam-epoch looks like it'd solve that issue by preventing the need for a transmute by keeping the Mutex/Bitmap from being deallocated until they are done being used. (the thread being unpinned.)

My only issue is that crossbeam-epoch doesn't seem to have a safe API- and on top of that it's very unclear based on the documentation how to properly use it.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

No branches or pull requests

1 participant