Re: Lua 5.1 threads, environments, and 5.2

[Anthony Howe <achowe+lua@...>]

On 12/04/2011 11:23, Tony Finch whispered from the shadows...:
> Why not just pass the client info table to the hook as an argument?

Because it is not convenient when you have lots of support functions.
The script writers have to know to pass that info around. Easier just to
put it in the thread's scope.

Also there are other tables passed in the threads scope. Sure I could
bundle them into one parent table, but still means that a script writer
has to remember to pass the context around.

> Just have a state object (i.e. table) per connection. No need to create a
> coroutine thread per connection unless you want a persistent thread of
> control. Your talk about hooks and callbacks suggests to me that you do
> not have a per-connection thread of control in your client code.

Corotinues needed to handle async IO event model. The application is
single process single threaded (OS-wise) and multiplexing IO. The Lua
scripts can make network IO requests (dns, mail, http, etc.), during
which another client connection might get service, due to multiplexing.
So a Lua thread per connection is used and allows resumption of a Lua
hook function once the IO event triggers or timesout.

The only way to handle async IO events nicely is using coroutines, which
means Lua threads. The only way to load once and avoid creating new Lua
state and reloading the scripts from disk is to use Lua threads spawned
from the master state image; Lua has no fork or clone state function.
Depending on the size of the script and 3rd party libraries it could be
saved in memory and then used to load new Lua states using
luaL_dostring(), but I suspect that would have its own issues.

-- 
Anthony C Howe            Skype: SirWumpus                  SnertSoft
                        Twitter: SirWumpus      BarricadeMX & Milters
http://snert.com/      http://nanozen.info/     http://snertsoft.com/