lua-users home
lua-l archive

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

On 3/1/08, Duck <> wrote:
>  Incidentally, it sounds as though what you are building isn't really
>  LuaSocket 3, but LuaAsynCore 1, so it seems as though there is a case for
>  naming it as a new library, and keeping LuaSocket 2 as an alternative, and
>  more traditional, socket-specific API for those Lua users to whom it's
>  sufficient, more comformatable, etc. In other words, reflect the
>  difference in nomenclature as well as implementation.

i'd second this idea.

as an anecdote, some time ago, i tried to develop a similar
infrastructure, to have all kinds of I/O under one single
event/queue/select/whatever.  searching for event-driven libraries,
some were quite flexible, but in the end required the I/O to signal
availability on a file or file-like object.  that clearly left out any

the only solution i could think of was using helper threads, that is,
create a thread that blocks and signals the main one when the task was

and that's the story behind Helper Threads Toolkit.  unfortunately,
the two requirements that stem from this approach (new I/O libraries
and pthreads) has made it totally uninteresting for almost everybody.

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

now the next challenge would be to create a split SQL library, to
isolate the blocking API in a second process, using IPC to expose a
non-blocking SQL API.