On Tuesday 31 January 2006 1:12 am, Adrian Sietsma wrote: > The simplest (and fastest ?) model here would be to have the main loop > in c(++), using os threading and events to run each lua callback in it's > own lua state (vm). We found this model perfect for a specific large > commercial task. since there's been a lot of previous work on this subject in c(++); it's relatively easy for a specific project to choose one model and go with it. but to make it usefull for everybody, the Lua way would be to get a nice set of primitives and let the user build his own dispatcher. i'm trying to write something (currently in the third rewrite since the thread started) that would provide a single Lua interface to build the dispatcher, and at the same time, a simple set of C routines to build IO libraries. at the moment, my model is a bit like this: the library writer splits each potentially blocking operation in three C functions: int (*begin)(lua_State *L, void **userdata); void (*work)(void *userdata); void (*end)(lua_State *L, void *userdata); when the Lua developer calls the function, only the begin C function is called; it sets up it's userdata, and the framework returns a "future" to the Lua code. all futures are contained in a queue, and a set of helper threads call the work functions asynchronously. this work functions can't modify the Lua State. when finished, the framework puts the future in the 'done' queue. the dispatcher (written in Lua) calls a function that returns the done futures from this queue (might block if there's nothing there). with the 'done' future, the Lua code calls a 'finish' method, the end function is executed, and any data from the operation is returned. this is (i think) enough to write a simple dispatcher: just wrap the new nonblocking operations so that they yield out of the coroutine 'thread' with the future; the dispatcher associates the unfinished future with the thread, and resumes it when this same future comes out of the done queue. the wrapper calls the finish method and returns the result to the original caller. i'm still mangled in code; mostly about who gets the responsibility to dealloc the futures, and if they should be reused for sequential operations. any opinions? -- Javier
Attachment:
pgpZGTqCETwoe.pgp
Description: PGP signature