Re: LuaSocket 3.0? (was Re: A proposal for faster userdata type checking)

[Duck <duck@...>]

>so, if the new LuaSocket (or LuaAsynCore :-) can handle 
>any file-like object, it could be a great foundation for 
>all kind of servers

...and if one of the file-like objects it can handle is some sort of 
inter-task message-passing queue (e.g. as used in LuaTask for task 
synchronisation with task.post() and task.receive()) then it would be 
possible to use the LuaNewSocket library in conjunction with that 
multithreading library in order to work with, say, database backends which 
use blocking I/O.

At the moment, the problem with LuaOldSocket and a server library such as 
COPAS is that you can only afford to block indefinitely at exactly one 
place, namely COPAS's central socket.select().
 
That means that if you also want to get data from, say, a LuaTask message 
queue so you can await replies from DB queries running in subtasks and 
then relay the replies to waiting sockets...then you have to use a 
busy-waiting loop. You need to to block briefy at a COPAS-style 
socket.select(), then block briefly at a LuaTask task.receive() -- so the 
system behaves atrociously under light load (or when all connected sockets 
are waiting for replies from sub-tasks).

Some potential integration between LuaNewSocket and a mainstream Lua 
mutitasking library would therefore be very handy, for example if the two 
libraries had some sort of very fast IPC mechanism in common. (Maybe pipes 
are good enough? Maybe not. LuaTask, IIRC, uses a combination of shared 
memory for its IPC message data, and pipes -- or semaphores on Windows 
-- merely for synchronising access to the shared memory.)