Why does mlua hold a lua state lock across an entire resume call

[cheesycod]

Been trying to debug a strange locking issue in send mode and found that mlua seems to hold a lock around lua across en entire Thread::resume call. Won't this lead to issues if another thread tries to perform operations on the lua VM while in a lua thread resume [aka, shouldnt mlua release the lock before the resume and then relock or am I not seeing it correctly]

[khvzak]

The main purpose of the lock is to protect Lua VM. If release the lock before Thread::resume call, then another thread waiting for the lock will acquire it, get access to the VM and can execute any operations. Such scenario is not supported by Lua and will cause UB.

[cheesycod]

Oh ok, thanks for the explanation

[cheesycod]

@khvzak i also managed to solve my deadlock issue too

Turns out that holding a AppDataRef actually locks the Lua VM until its dropped which then led to a really bizzare deadlock in my code.

Just leaving this here in case someone else runs into deadlocks while using app data in mlua

[khvzak]

This is right, the app data container uses the same mutex and every reference holds a guard. Otherwise it would require double mutex lock for every access to the app data.
The best practice is to keep AppDataRef lifetime as short as possible.