Re: Lua registry, environment, and threads.

[Patrick Donnelly <batrick@...>]

On Wed, Jan 6, 2010 at 11:51 PM, Mark Hamburg <mark@grubmah.com> wrote:
> On Jan 6, 2010, at 9:03 AM, Roberto Ierusalimschy wrote:
>
>>> Does that mean in 5.2, I can't have any per-thread data? It has to
>>> be global to a Lua state or private to a function?
>>
>> Note that in 5.1 the built-in per-thread data is not very useful, as you
>> cannot access it from Lua. (That is the main reason why we are removing
>> it).
>>
>> In C, it is not difficult to use the thread itself as a key to store
>> per-thread data in the registry, if necessary.
>
> I could see an argument for still supporting C access to an environment table attached to a thread. As with the environment table attached to userdata, it wouldn't be particularly "environmental" but it eliminates one case where I would assume one would otherwise need a semi-weak table. I know 5.2 has the new marking logic for semi-weak tables, but I also know that logic is potentially expensive depending on the actual graph structure so it seems like a good idea to provide alternatives where feasible.

I personally feel that keeping the environment table for threads is a
good idea (if for no other reason than some limited backwards
compatibility) but I feel it's worth noting how confusing the name is.
At the risk of speaking for the masses, many people miss that userdata
have an environment table. (Similarly, most do not understand the
subtleties of how the thread environment and function environments
interact. It's definitely a good thing this is being reviewed in 5.2.)
When I was first learning the C API, I would rely on logical API names
to find what I needed. The name for userdata tables, "environments",
is convenient for a smaller API but not at all for the user (the guy
embedding Lua). I would propose a new macro be added that can be used
to retrieve a thread or userdata table. The new name would better
describe what is being retrieved while allowing for easy
implementation (lua_getfenv is still called and works for all three
types). The documentation could also better emphasize that
thread/userdata tables are not used by Lua directly.

Also, getfenv(0) and sefenv(0, ...) can access the current thread's
environment (which means that there is the potential for plain Lua
code to be affected).

-- 
-Patrick Donnelly

"Let all men know thee, but no man know thee thoroughly: Men freely
ford that see the shallows."

- Benjamin Franklin