 |
lua-l archive |
|
|
||
|
On 23/06/15 04:00 AM, Dirk Laurie wrote:
debug.getmetatable(luastate, object) and debug.setmetatable(luastate, object, newmt) (luastate would only be relevant for nil, boolean, string, function, lightuserdata, thread; all other types have per-object - instead of per-state - metatables), debug.getregistry(luastate) and a debug.setregistry(luastate, newregistry) that lets you replace the registry (e.g. replace a coroutine's registry so that it can use your own custom registry, with a custom global environment - PROBABLY wouldn't accept the main thread as an argument - these can NOT be simulated, but my "250 LOC beast" can simulate per-thread debug.(s/g)etmetatable)2015-06-23 3:51 GMT+02:00 Soni L. <fakedme@gmail.com>:Why can't we get a way to make independent Lua states from Lua, anyway? (or rather with isolated registry and global metatables - this means the GC would be shared between them, thus allowing objects to be shared between them, but they wouldn't share the same global metatables or the same globals table). It would open up great possibilities!The presently available language features in that direction are: 1. debug.getregistry()[1], which contains the Lua state, and debug.getregistry()[2], which contains the global table. These are assignable. By "global metatable", do you mean things like getmetatable("")? 2. Coroutines. 3. Loading code with a specified _ENV. What additional functions, callable from Lua, would you need for your envisaged ability? Can you describe them in terms of currently available API routines, so that one can knock together a little module in order to experiment with the idea?
By default every new thread (aka coroutine) would inherit the creator's metatables and registry.
-- Disclaimer: these emails are public and can be accessed from <TODO: get a non-DHCP IP and put it here>. If you do not agree with this, DO NOT REPLY.