lua-users home
lua-l archive

[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index] [Thread Index]


After looking a bit deeper I think I can set the _ENV for the script I load into the thread using luaL_loadstring by lua_setupvalue to the environment table I want. That way the script running in that thread will have its own environment.
       Is there a problem with this approach?

Thanks,
Milind



On Fri, Apr 4, 2014 at 8:07 AM, Milind Gupta <milind.gupta@gmail.com> wrote:
Yes, I was hoping for the same. A read only for the global environment and individual environments for each thread, if that is possible anymore.

Thanks,
Milind


On Fri, Apr 4, 2014 at 8:05 AM, Coroutines <coroutines@gmail.com> wrote:
On Fri, Apr 4, 2014 at 7:59 AM, Javier Guerra Giraldez <javier@guerrag.com> wrote:
On Fri, Apr 4, 2014 at 9:49 AM, Milind Gupta <milind.gupta@gmail.com> wrote:
> I think that it would be more memory efficient if I create just 1 lua state
> and run all the threads in that, each with its own environment. Is that
> true?


no

the issue is not about the environment, but about sharing the whole
state.  it's a complex memory data structure fairly optimized for
single-threaded access.  it's definitely _not_ threadsafe as is.

it's not too hard to wrap every access to the state with mutex locks,
but then i amount to a GIL (global interpreter lock), which makes all
Lua code serialized and with a heavy lock/unlock overhead.

long time ago, I dabbled on lock-free datastructures and managed to
create a few that could be used from Lua, but they're much harder to
get right than 'traditional' lock-based threadsafe programming.  In
the end, it's better to have several Lua states that communicate by
message passing.

just my 2¢

--
Javier


You'd think that read-only access to the a shared global_State from different lua_State's (coroutines.create()) would be possible without a global interpreter lock.