Re: Coroutines, sockets and multiplexing

[Javier Guerra <javier@...>]

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: pgpiThf2Jnkos.pgp
Description: PGP signature