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

[WIP] Add a LuaMutex type to borrow the InsideCallback #118

Open
wants to merge 1 commit into
base: master
Choose a base branch
from

Conversation

tomaka
Copy link
Owner

@tomaka tomaka commented Dec 29, 2016

Fix #10

Blocked by rust-lang/rust#38673

Changes are:

  • The parameters of a Rust function passed to Lua must now implement LuaRead<&InsideCallback> (right now it's LuaRead<&mut InsideCallback> + 'static, which is a hack)
  • All basic types (String, integers, etc.) already implement LuaRead<&'a InsideCallback> so they will still work.
  • Types such as LuaFunction or LuaTable do not implement LuaRead<&'a InsideCallback>.
  • A new type LuaMutex<T> (where T can be LuaFunction or LuaTable) does implement LuaRead<&'a InsideCallback>.
  • The LuaMutex struct has a lock function that locks the InsideCallback and reads the T. As long as the T is alive, no other LuaMutex 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 example table1 by calling table1.lock(). The lock function will return a LuaTable.

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 this LuaMutex system.

@tomaka
Copy link
Owner Author

tomaka commented Dec 29, 2016

Also added the 'lua lifetime to InsideCallback to fix soundness.

@tomaka
Copy link
Owner Author

tomaka commented Jan 4, 2017

I managed to make it work for InsideCallback<'static> only. Since this is the most common case, I'm going to push the change and fix this later.

@tomaka
Copy link
Owner Author

tomaka commented Jan 4, 2017

The current code is still unsound because it allows reading and writing the same userdata simultaneously.

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

Successfully merging this pull request may close these issues.

1 participant