[Date Prev][Date Next][Thread Prev][Thread Next]
[Date Index]
[Thread Index]
- Subject: Re: Multiple functions: was the gc
- From: Wim Couwenberg <w.couwenberg@...>
- Date: Thu, 24 Aug 2006 21:41:52 +0200
> I myself wanted to be able to alter functions to use the globals of
> the thread in which they are invoked as opposed to having the hassles
> of managing multiple closures for multiple lua threads.
No hassle. My previously posted example uses only a *single* closure
for each thread (have a peek.) However...
... lua_setfenv/setfenv() with nil as the
special value that indicates the environment should be the "dynamic
environment". By that meaning use the environment of the current thread
as opposed to the inherited environment at creation time.
I like this idea (reminds me of the Lua 4 days too...) and would like to
add another suggestion: store the environment of a closure in an UpVal
and pass the UpVal pointer around instead of the raw Table pointer.
(This was suggested to me a *long* time ago by Rici. Where is he by the
way?) This has the advantage that a setfenv changes the environment of
all "related" closures at once, e.g. all closures defined in a single
script/module. This makes the "single level" setfenv problem mentioned
by Willieam Ahern go away in many (all?) relevant cases.
--
Wim