Why does cloning values need to lock the Lua VM

[cheesycod]

Why do things like ValueRef need to lock the Lua VM and push a new reference for a clone. Would it not be more performant to instead wrap the inner contents of the ValueRef in a XRc like how the Lua VM itself is cloned?

E.g.

pub struct ValueRefInner {
    pub(crate) lua: WeakLua,
    pub(crate) index: c_int,
}

impl Drop for ValueRefInner {
    fn drop(&mut self) {
        if let Some(lua) = self.lua.try_lock() {
            unsafe { lua.drop_ref(self) };
        }
    }
}

/// A reference to a Lua (complex) value stored in the Lua auxiliary thread.
#[derive(Clone)]
pub struct ValueRef {
    pub(super) inner: XRc<ValueRefInner>,
}

impl Deref for ValueRef {
    type Target = ValueRefInner;

    fn deref(&self) -> &Self::Target {
        &self.inner
    }
}

For context/further clarification, The Go bindings for Luau that im working on (gluau) rely on being able to clone ValueRef's for basically everything due to safety concerns and due to goroutines, these clones may occur over multiple threads leading to performance loss. Hence why I am considering to switch to XRc in my fork of mlua. I just wanted to know if there was a specific reason for the current design.

As an additional thing, the way valueref's are cloned might also be a contributing factor to why I was exhausting the auxiliary thread stack lol (#590)

[khvzak]

As I remember, mostly historically. I'll take a look to it and make improvements.

[cheesycod]

Oh ok, thanks for letting me know as I came across this while trying to improve the performance of gluau's clone ops across goroutines so I didn't want to introduce unsafety anywhere