lua-users home
lua-l archive

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


One task that I have for making a project fully safe is to setup an
API that I expect to be well abused in the following ways:
 * Call w/ bad pointer values
 * Call from any # of threads
 ... well thats about it

Bad pointer's were fixed by using a 'set' of valid pointer/handle values.
Threads were fixed by serializing parts and mixing in some Lua
multithreading code introducing global locks which has caused some
ugly issues to arise and be managed...  We also used Lua
multithreading 'internally' from the perspective of our code created
threads to do certain things.

Lanes seems to be the savior from the standpoint that it can grant us
the multi-threading, particularly on 'internal' threads.

The only gotcha that wasn't entirely clear was how in the world to
handle the problem of external threads.

My idea is this:

 API initialization sets up a 'core' Lua state that manages setup/etc.
 Another state is created to do actual work based on requests coming
through a Linda from the 'core'.  External states are created and
setup w/ the same communication channel as the worker states.

ASCII Draw:

EXT1 ----\__CORE__/---- WORKER[*]
EXT2 ----/

As for hooking EXT* to the Linda to communicate w/ the workers... I
was in luck to discover that Linda's are quite simple to copy:
luaG_inter_move - a utility function that moves Lua values between
states (simple values + deep userdata, no normal userdata or
coroutines)

Pseudocode for usage:
Main:
 * init main state
 * create Linda for work
 * create workers - semi-optional since the main state could do work
 * let the main lua state run 'idle' (sleep, wait on sockets, etc...)
   not 100% sure if this is required... pretty sure it is
External:
 * init state
 * get lock on main state
   * call function to retrieve the Lindas used
   * luaG_move_Inter( MAIN, EXT, [# of lindas])
 * release lock
 * run as normal and just talk through Lindas
-- 
Thomas Harning Jr.