[WIP] Add a LuaMutex type to borrow the InsideCallback #118
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Fix #10
Blocked by rust-lang/rust#38673
Changes are:
LuaRead<&InsideCallback>
(right now it'sLuaRead<&mut InsideCallback> + 'static
, which is a hack)LuaRead<&'a InsideCallback>
so they will still work.LuaFunction
orLuaTable
do not implementLuaRead<&'a InsideCallback>
.LuaMutex<T>
(whereT
can beLuaFunction
orLuaTable
) does implementLuaRead<&'a InsideCallback>
.LuaMutex
struct has alock
function that locks theInsideCallback
and reads theT
. As long as theT
is alive, no otherLuaMutex
can be locked.So for example if you want a Rust function that takes two tables as parameter, you can pass a closure like
|(table1: LuaMutex<LuaTable<_>>, table2: LuaMutex<LuaTable<_>>)|
. You can then read for exampletable1
by callingtable1.lock()
. Thelock
function will return aLuaTable
.As long as the
LuaTable
is alive,table2
can't be locked.See #10 for an explanation about why this is necessary.
A future change is to allow
LuaRead<&mut InsideCallback>
if there is only one parameter, which would allow closures with only one parameter to bypass thisLuaMutex
system.