Re: thread state and dynamically loadable library

[Doug Currie <doug.currie@...>]

Monday, September 4, 2006, 11:26:06 PM, D Burgess wrote:

> I think you have thought of most of the alternatives. I had a similar
> problem and used lazy initialization which tests if the thread
> LUA_GLOBALSINDEX is the same table as the main thread
> LUA_GLOBALSINDEX, if they are the same I create a thread
> globals table that is metatabled (__index) to the global table
> of the main thread.

OK. What technique is used to decide what table is the main thread
LUA_GLOBALSINDEX? I suppose you could use a rawget to see if the
loadable library's table is in the LUA_GLOBALSINDEX, and if it is,
conclude that that table must be the top level table. But if the
loadable library's table isn't there, can you conclude that this table
is unique to the thread?

What happens when a thread that has already been lazily allocated a
thread globals table spawns sub-threads? These will inherit the
library created thread globals table. How do you know to create yet
another such table in the child threads?

I suppose you could create a key in each thread globals table that
refers to its thread (L), and check this every time you use it (along
with the check that the loadable library's table isn't there). This
would prevent tables from being inherited. But, yikes, this is getting
to be an awful lot of overhead just to get a pointer to a thread
context.

e

-- 
Doug Currie
Londonderry, NH