Re: Q: Lua 5.2 thread environments...

[Anthony Howe <achowe+lua@...>]

On 30/03/2011 20:49, Patrick Donnelly whispered from the shadows...:
> On Wed, Mar 30, 2011 at 2:11 PM, Anthony Howe <achowe+lua@snert.com> wrote:
>> >From the 5.2 alpha documentation, section 8.1 – Changes in the Language:
>>
>> "Threads do not have individual environments. All threads share a single fixed environment.
>>
>> This doesn't sound good.
> 
> It is good. Threads don't have "environments"; functions do. What the
> quote above really means is Lua no longer has a per-thread context.
> (Of course, this per-thread context only applied to C closures using
> LUA_GLOBALSINDEX...) It doesn't really make sense and can be easily
> emulated through function environments and closures.

Hmm. I'm not clear on this, since I have another issue related to function environments that would indicate to me thread
environments should be kept and function environments removed (as they seem more problematic in setting up; at least they have been
for me).

For example in 5.1 I can define in the master

function helper(x)
	syslog.debug(client.ip.." x="..x)
	...
end

function hook.connect()
	syslog.debug("client.ip="..client.ip)
	...
	helper(foobar)
	...
end

I can set up the thread environment and the function environment of hook.connect() to confine it to thread (one thread per client
connection with details of the connection is "client" table for each thread).
	
I've found that a function call chains do not inherit the environment of the caller, hook.connect() is fine, but in helper(),
reference to client.ip throws an error "attempt to index global 'client' (a nil value)" or something to that affect. I've not
figured out or found a clear example of how to force function calls to inherit the context of the parent function call.

I'm worried that this will be compounded in 5.2 with the proposed dropping of thread environments.

>> In my current network application I am developing, I rely on the ability for threads to have separate "environments" (contexts) in
>> order to ensure that data placed into the thread's global space does NOT appear in another thread's global space or the master state
>> from which the thread was originally created.
> 
> You can still do this. Thread specific data can be kept in a weak
> table within the registry. Alternatively you can maintain state

That's kinda poor. I don't want to have to store context in the registry when it its better attached to the object in question, in
this case a thread so that they all are gc'd together when the thread is discarded.

> through closures and upvalues.

>From what I understand of this, upvalues are confined to a single C closure Now if I can share an upvalues between several C
functions that might work, but not sure how to express that and when you have MANY functions to share amoung, that sounds rather
cumbersome when you could have easily confined scope to the thread in one set of operations.

There have been to few examples of how to do what I want in 5.1 and none I've seen in 5.2 that I see this change as for worse, not
better. Currently when I create a new thread in 5.1 I do this:

static void
lua_thread_newenv(lua_State *L)
{
  lua_newtable(L); 				/* new_G  */
  lua_pushvalue(L, -1);				/* new_G new_G */
  lua_pushliteral(L, "__index");		/* new_G new_G __index */
  lua_pushvalue(L, LUA_GLOBALSINDEX);		/* new_G new_G __index old_G */
  lua_settable(L, -3);				/* new_G new_G */
  lua_setmetatable(L, -2);			/* new_G */
  lua_replace(L, LUA_GLOBALSINDEX);		/* -- */
}

In 5.2 it sounds like this will not be possible. (Yes I know LUA_GLOBALSINDEX changes name in 5.2.)

>> How will a thread ensure that data defined within it remains confined to that thread? Currently I rely on changing the thread's
>> LUA_GLOBALSINDEX to a metatable assigned to the thread that confines data.
> 
> There is no LUA_GLOBALSINDEX in 5.2.
> 
> Again, use a weak table in the registry for thread specific data.

Sounds like rubbish when you expect to have 1000's of threads, one per client connection.

-- 
Anthony C Howe            Skype: SirWumpus                  SnertSoft
                        Twitter: SirWumpus      BarricadeMX & Milters
http://snert.com/      http://nanozen.info/     http://snertsoft.com/