Re: Cloning "preforked" Lua state

Subject: Re: Cloning &quot;preforked&quot; Lua state
From: Michael Surette &lt;mjsurette@ ... &gt;
Date: Sun, 06 Sep 2009 13:12:28 -0400

All threads would use the same ***instance*** of all globals, so if you save something in a global variable in one thread, it affects all threads. This is a very undesirable trait in server threads. If you forget to make a variable local and write to it you have a problem.

I hate to say it, but I think that this is a flaw with Lua. Most of the time you want to declare locals, and that should be the default. Compare the usage frequency of Lua's 'local' keyword to Python's 'global' keyword; the difference is very significant.

This then gives us the the problem of context, that is saving state from one subroutine call to another in a given thread. You can't use globals. In the past I've used per-thread tables that I pass to all subroutines, which works, but this idea of cloning threads sounds like it might be a more natural feeling solution to this problem.

Sorry, by "thread" do you mean kernel thread or Lua coroutine. This is another thing that irks me, the confusion of terminalogy surrounding Lua's coroutine support; A coroutine is alternately described as a coroutine or a thread, and is of type lua_State. This is confusing to sort out at first, and impedes communication in the case where there is even a slight ambiguity of context.

And then you said, "cloning threads". I thought we were discussing cloning lua_States (sigh) which are not coroutines.