Guided Tour implies no GC running when using Scope about rlua HOT 2 CLOSED

Changed the documentation in the guided tour, hopefully this is clearer.

Also for future reference in case somebody looks at this issue, what I wrote about UserData types requiring 'static is no longer true, Scope can now lift both Send and 'static requirements.

from rlua.

Yeah the GC is running in a call to Lua::scope for sure, the text "lifting both of these restrictions" is meant to reference the fact that userdata must be Send and 'static. I'll figure out a better way of wording it, or simply drop the reference to the GC at all.

The reason I mention the GC is because that is the reason WHY userdata must be 'static: since we don't know when Lua will get around to garbage collecting our userdata, we can't make any assumptions about the lifetimes of any references in the userdata. Lua::scope forces the userdatas to be destructed at the exit of the scope.

Edit: also, similarly, this is why we can let userdata be Send. In the context of a Lua::scope call, Lua has a live reference, so it would be impossible to give that Lua to another thread while inside a scope call. Since all the userdata created in a scope will be forcibly dropped at the end of the scope call, it's okay if they aren't Send since you could never store !Send userdata inside Lua long term.

Unfortunately, you can't take away the 'static restriction on UserData types because they are accessible based on TypeId, and that is sort of fundamentally unsafe with non-'static types (you can manufacture any lifetime you want inside a UserData method).

Note: I'm using lowercase 'userdata' here to refer to the Lua concept of userdata, which in this case includes both callbacks with state and also types that implement the UserData trait.

Edit 2: I guess mentioning the GC at all is really unnecessary, as there are really countless ways of Lua extending the lifetime of something, I'll just reword it to not mention the GC at all.

from rlua.