lua-users home
lua-l archive

[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index] [Thread Index]


It was thus said that the Great Soni L. once stated:
> On 23/06/15 08:20 PM, Philipp Janda wrote:
> >Am 23.06.2015 um 21:02 schröbte Soni L.:
> >>
> >>and
> >>
> >>TValue l_registry;
> >>
> >>out of the global_State and into the lua_State.
> >
> >And then `io.open` wouldn't find its metatable when called from within 
> >a coroutine, C libraries would be loaded and gc'd multiple times, etc. 
> >...
> >
> How's that any different from creating multiple global states?

	L1 = luaL_newstate();
	L2 = luaL_newstate();

  L1 and L2 are distinct global states.  They each have their own GC and
registry (among other things).  The registry gets populated by various
values.  For instance, in Lua 5.3, by the time you get the Lua prompt, the
following is already in the registry:

	1                    thread: 0x9ffe00c   
	2                    table: 0x9ffe3c0    
	_PRELOAD             table: 0x9fffc58    
	_LOADED              table: 0x9ffeb60    
	FILE*                table: 0xa000428    
	_IO_input            file (0xcbc720)     
	_IO_output           file (0xcbc5c0)     
	userdata: 0x806c180  table: 0x9ffefc8    

  And as I've found out the hard way (this evening) if you attempt to clean
this out (to simulate an empty registry), Lua does not like it very much:

> registry = debug.getregistry()
> registry[1] = nil
> registry[2] = nil
attempt to index a nil value
[spc]lucy:~>

So it's a bit more work to get a "clean" registry than I initially thought. 
Giving each coroutine its own registry would be ... interesting (in the
Chinese meaning [1]).

If you copy the registry over (or more likely, reference) then there's no
difference from the way things are now.  

  Soni, I think your best best is to wrap Lua up into a Lua module.

  -spc (Getting flashbacks to running Castle Wolfenstein on an Apple ][
	emulator under an Amiga emulator under Windows under Wine ... )

[1]	May you live in interesting times.
		-- Chinese curse most likely.