[Date Prev][Date Next][Thread Prev][Thread Next]
[Date Index]
[Thread Index]
- Subject: Re: GCed dynamic libraries
- From: Edgar Toernig <froese@...>
- Date: Fri, 2 Jul 2004 16:07:15 +0200
Roberto Ierusalimschy wrote:
>
> > Hmm... just in case you want to extend the "function environment" to
> > C-functions by replacing the private registry with private globals:
>
> Is there any difference? Each function has a pseudo-index for the
> registry (the "real" one), a pseudo-index for the global table (the
> "real" one), and a pseudo-index for its own private table.
As long as there are those three indexes I'm fine.
[I don't really care how the third index is named - my first name
was PREGISTRY (private registry). Only later I changed that to
REGISTRY and made the old registry (the "real" one) the COREREG-
ISTRY. Required less changes to code - nearly all registry users
need a private registry to make GCing work and there were only
two places where the core registry was needed.]
What I feared was that you make the global table accessed via
LUA_GLOBALSINDEX the per library private table - that is, only
two special indexes, LUA_REGISTRYINDEX as before, and
LUA_GLOBALSINDEX for a private globals table - like the environ-
ment in Lua functions.
> We can call it a "private registry" or a "private environment" (or a
> "private global table" :), but the mechanism is the same.
The mechanism is the same, but the intend is different. I don't want
to see lua_setglobal to put something in a private environment nor
would I like to see a script to change my private data because it has
access to or shares my environment.
Ciao, ET.